What's on the other side of self-hosting?

There is a familiar picture of self-hosting: a server in a cupboard, a weekend lost to YAML, and one person who can never fully go on holiday.
On the other side is software as a service: enter a card, invite the team and let somebody else absorb the operational anxiety.
That distinction used to feel complete. It no longer does.
Managed software keeps becoming more expensive. AI adds variable inference bills to already crowded SaaS budgets. Data sovereignty is becoming a product requirement rather than a procurement footnote. At the same time, open-source software, cheap compute and local models make ownership more technically possible than ever.
And yet most people still do not self-host.
The interesting question is not whether they are irrational. It is whether self-hosting is still packaged as the wrong product.

Why would anyone choose to operate their own software?

A former co-founder recently made the case against the excitement around self-hosted legal AI. His central point was simple:

“People have always wanted the comfort of a managed service.”

Engineers have long been capable of deploying open-source alternatives, but most still pay for hosted tools. Law firms already outsource email, document management, practice management and often their entire IT function. Expecting them to suddenly operate model updates, retrieval pipelines and evaluation systems is not a serious deployment strategy.
LibreOffice does not displace Microsoft Word merely by being free. Mattermost does not automatically displace Slack merely by being self-hostable. Building a Linux workstation can provide more compute per dollar than buying a Mac, but that does not make assembling and maintaining it a good use of everybody’s time.
The argument is not that open source is bad. It is that software ownership and software operation are different jobs.
A repository does not provide accountable upgrades, tested restores, observability, capacity planning, security response, identity integration or predictable recovery when its installer is unavailable. The managed-service premium pays for those outcomes. Comparing a subscription with a server price ignores what customers are actually buying.

Open source is mainstream; self-operation is not

The Linux Foundation’s 2025 research describes open source as mission-critical and widely embedded in enterprise technology, while organizational maturity still lags. Only 34% of surveyed organizations had a clear open-source strategy, and 26% had an Open Source Program Office. Production users increasingly expected commercial-grade response times, long-term support and rapid security patches. Technical support and security remained major barriers.
That is the paradox: open source already won inside the stack, but the operational burden around it did not disappear.
Self-hosting remains culturally prominent and operationally narrow. It thrives among enthusiasts, infrastructure teams, privacy-sensitive users and organizations with a strong regulatory or economic reason to own deployment. That is not broad adoption by ordinary businesses.
The usual explanation is convenience. True, but incomplete. People run online stores without becoming payment experts and publish globally without becoming CDN engineers. They accept complex systems when the difficult parts are made legible and somebody remains accountable.
Perhaps self-hosting remains fringe because it is sold as components rather than a managed outcome.

Pressure from the other side

The managed model is comfortable, but its economics are harder to ignore.
The FinOps Foundation’s 2026 survey covered 1,192 respondents responsible for more than $83 billion in annual technology spend. FinOps is expanding beyond public cloud into SaaS, licensing, private cloud and data centres because the old categories no longer describe how organizations spend money.
This does not mean every workload belongs on a local server. It means “put it in the cloud and stop thinking about infrastructure” was never the final abstraction.
Costs compound through seats, tokens, storage, egress, observability, backups and duplicated tools. Changing vendors means migrating data, workflows, identity and institutional memory. The price can rise while the practical cost of leaving rises with it.
There are credible cases where ownership changes the economics. 37signals reports that moving stable applications from public cloud to owned hardware saved about $1 million per year without adding staff. That is not a universal formula. It worked because the company had predictable workloads, operational competence and enough scale to amortize hardware and labour.
A five-person startup and a mature software company should not read the same result as the same instruction.

The real cost equation

The comparison is not a server price against a SaaS bill. It is the operating cost of two different models:

Founder time belongs in the equation even when no salary leaves the bank account.

Cost	Managed service	Traditional self-hosting
Infrastructure	Recurring; scales with seats or usage	Lower fixed compute cost
Setup	Low	Engineering time
Routine operations	Included	Recurring obligation
Recovery	Vendor responsibility within contract limits	Team responsibility
Data and customization	Product constraints	High control
Exit	Often harder over time	Easier if formats stay portable
Dependency	Vendor	Internal operator

For a small team, saving a few hundred dollars monthly is a poor trade if deployment consumes founder-days and creates indefinite maintenance. The payback period may exceed the runway.
The equation changes when workloads are stable and continuously utilized; SaaS pricing scales sharply; hardware has spare capacity; locality has legal or commercial value; multiple applications share one substrate; and deployment, upgrades and recovery are automated.
The bootstrapping benefit does not come from eliminating operations. It comes from amortizing operations across owned workloads.

The missing category

The debate usually offers two choices:

1. use the vendor’s SaaS;
2. download the repository and become its operations team.

There is a large design space between them.

Managed control plane, owned data plane

Applications and customer data run on customer-controlled infrastructure. A hosted control plane handles deployment intent, policy, health, upgrades and fleet coordination.
Opaque documents this pattern: the customer retains data and compute while a hosted control plane provides orchestration and platform intelligence. Confluent similarly separates cloud governance from self-managed data processing.
The boundary must be real. The control plane should not quietly become a copy of the data plane.

Local steady state, cloud burst

Predictable baseline work runs on owned infrastructure. Temporary demand, exceptional jobs and recovery capacity use cloud infrastructure. The local system does not need to be sized for the busiest hour of the year.

Local models, managed fallback

Sensitive or repetitive inference runs locally. Requests needing a larger model, unusual capability or temporary capacity go to an approved provider. GitLab already supports cloud, self-hosted and hybrid model choices.
The product is not merely a model selector. It is policy: which data can leave, what may burst, what it can cost, and what happens when the provider is unavailable.

Customer-owned infrastructure, managed operations

The customer owns the machine or account; another party owns patching, backup verification, incident response and lifecycle management. This preserves economic and jurisdictional control without pretending every customer wants an SRE team.

Managed first, exit-ready

Start hosted, but continuously preserve portable data, declarative configuration and a tested path to customer-controlled infrastructure. Early speed can matter more than infrastructure margin. Later, stable workloads and rising bills may justify moving selected services. Exit readiness makes that an economic choice rather than a rewrite.

Hybrid can be worse

Hybrid can create the worst of both worlds: a SaaS bill plus fragile local infrastructure. A credible product needs a hard contract.

Responsibility	Managed layer	Customer layer
Desired state and policy	Yes	Mirrored locally
Application data	Minimal metadata	Yes
Secrets and keys	Preferably no	Yes
Health and updates	Orchestrates	Executes locally
Workload execution	Optional burst	Default
Backup	Verifies	Stores encrypted data
Offline operation	Coordination degrades	Core workloads continue
Exit	Export supported	Customer retains assets

The architecture must answer: Can workloads continue if the control plane disappears? Can operators inspect every action? Are updates staged, verified and reversible? Can restores be proven? Can the customer leave without reconstructing the system? Who responds at 3 a.m., and what are they authorized to do?
Without answers, “hybrid” is only a diagram.

What this means for legal AI

The criticism of self-hosted legal AI is correct when self-hosting means handing a law firm a Docker Compose file and model card.
Production legal AI may require model and embedding upgrades, retrieval indexing, data lineage, matter-level access, evaluations, auditable outputs, cost monitoring and rollback when a change degrades quality.
Most firms will not build this function. Nor should they.
But it does not follow that every document, embedding, inference request and audit trail must live inside one vendor’s multi-tenant SaaS. A managed system can keep its sensitive data plane in the firm’s environment while lifecycle management remains a service.
The customer is not asking to operate RAG. The customer is asking to control where legal data goes, how costs scale and whether the system survives a vendor decision.
That is a product problem, not an ideological demand for self-sufficiency.

The GlobalStacks thesis

GlobalStacks should not make self-hosting feel like operating a small cloud. Its job is to make infrastructure ownership compatible with managed-service expectations.

The workflow is not “SSH in and run these commands.” It is:

1. Discover infrastructure and capabilities.
2. Show what an application requires.
3. Produce a bounded, reviewable plan.
4. Apply typed operations through a narrowly scoped agent.
5. Verify health, isolation, backup and recovery.
6. Keep configuration portable and exportable.
7. Route selected workloads to managed capacity under explicit policy.
8. Make rollback and migration ordinary operations.

That is not pure self-hosting. It is managed ownership.

How GlobalStacks approaches hybrid

GlobalStacks starts from a different premise: the deployment location should be a property of the workload, not the identity of the product.
A workload should be able to run on a machine in an office, a home server, a private data centre, a customer’s cloud account or managed burst capacity without becoming a different application each time. The user should describe the outcome, constraints and boundaries. GlobalStacks should translate those into a placement and operating plan.
That premise rejects both extremes.
GlobalStacks is not trying to persuade every team to own hardware. It is also not assuming that convenience requires surrendering the data, runtime and exit path to a single hosted platform. The goal is to preserve the managed experience while making ownership and placement explicit choices.

Hybrid begins with workload intent

The first question is not “local or cloud?” It is:

• What data does this workload handle?
• What latency and availability does it require?
• Is demand steady, bursty or unknown?
• Which external services may it contact?
• Where may its data, models and encryption keys exist?
• What is the recovery objective?
• What is the acceptable monthly cost?
• Must it continue operating if GlobalStacks is unreachable?

Those answers become policy. Placement follows from the policy instead of being hard-coded into the product.
A private document index may require local storage and local embeddings. A large, occasional inference job may be allowed to burst to a cloud model after approval. A public stateless frontend may belong on managed edge infrastructure. The application can span these locations without treating them as one undifferentiated network.

One control plane, multiple execution planes

GlobalStacks provides the coordination layer: desired state, plans, approvals, policy, update channels, health, drift, audit history and recovery evidence.
Execution remains distributed:

The control plane does not need general shell access or a copy of application data. A narrowly scoped agent executes typed operations in each environment and reports evidence back. The user can see what will change before approval and what actually changed afterward.
This creates a meaningful separation:

• GlobalStacks manages coordination.
• The customer retains workloads, data, secrets and infrastructure ownership.
• External providers supply explicitly permitted capabilities, not an invisible dependency on everything.

Placement is continuous, not permanent

Traditional deployment tools treat placement as an installation-time decision. Hybrid systems need to revisit it.
GlobalStacks should be able to recommend or perform a reviewed transition when:

• a prototype becomes a stable, continuously utilized service;
• cloud usage crosses the cost of fixed capacity;
• a workload begins handling sensitive data;
• local capacity becomes constrained;
• a temporary demand spike requires burst compute;
• a provider becomes unavailable or changes its terms;
• regulation requires a different data boundary;
• the operator wants to repatriate or migrate a service.

The unit of movement is the declared workload plus its policy, data contract and recovery procedure. Portability is not “we have a container image.” It means the destination can reproduce secrets, storage, networking, identity, health checks, backup and rollback without reconstructing undocumented knowledge.

Cloud is a capability, not the default destination

In the GlobalStacks model, cloud services remain valuable. They provide elasticity, global reach and specialist capabilities that are irrational to reproduce locally.
But they are consumed deliberately:

• a local model may call a larger hosted model for approved requests;
• steady-state compute may remain local while batch work bursts externally;
• customer data may stay local while anonymized or encrypted jobs leave;
• public ingress may terminate at a managed edge while the application remains private;
• managed object storage may hold encrypted backups while keys remain customer-controlled.

Each connection is declared through policy: destination, data class, budget, fallback and failure behavior. Hybrid is therefore not an accidental web of dependencies. It is a set of visible contracts.

The system must degrade honestly

A hybrid product is only credible if it explains what happens when one side disappears.
If the GlobalStacks control plane is unavailable, existing local workloads should continue running. New deployments, coordinated upgrades and centralized visibility may pause, but the customer’s applications should not stop merely because coordination is offline.
If a cloud capability is unavailable or its budget is exhausted, policy should choose among explicit outcomes:

• queue the work;
• use a smaller local model;
• switch to an approved secondary provider;
• reduce functionality;
• fail closed for sensitive operations;
• request operator approval for additional spend.

If the local environment fails, recovery should use verified backups and declared replacement capacity. “Hybrid” must describe failure behavior, not only normal routing.

Managed ownership is the product

GlobalStacks is not selling access to a dashboard that happens to deploy containers. It is selling the operational layer that makes owned infrastructure usable:

1. Discover machines, networks and provider capabilities.
2. Classify workloads by data, cost, latency and availability constraints.
3. Plan placement and every cross-boundary connection.
4. Approve bounded changes with visible effects and rollback.
5. Execute through narrowly permissioned local agents.
6. Verify health, isolation, backups and effective policy.
7. Optimize placement as utilization and economics change.
8. Exit by exporting state and moving workloads without vendor permission.

That is the GlobalStacks version of hybrid: not half-cloud and half-server, but a managed system in which compute can live in several places while control, responsibility and ownership remain understandable.

A framework for bootstrappers

Workload	Sensible default
Uncertain product, tiny team, changing requirements	Managed service
Stable, continuously used workload	Owned or fixed-cost hosting
Sensitive data with modest compute	Owned data plane, managed operations
Spiky portable jobs	Local baseline, cloud burst
AI with mixed sensitivity	Local models plus policy-controlled fallback
Commodity service with high operational blast radius	Managed unless recovery is automated
Strategic data or high switching cost	Exit-ready managed or hybrid

Ask four questions:

1. What are we buying with the managed premium? Name operational outcomes, not features.
2. Which cost scales badly? Seats, tokens, storage, egress, compliance, operator time or outage risk?
3. Which boundary matters? Data, keys, compute, control, vendor exit or all five?
4. Can ownership be operated as a product? If recovery depends on memory and terminal history, no.

What is on the other side?

The other side is not a world where everybody builds a server and abandons SaaS.
It is a world where “managed” no longer means the vendor owns every layer, and “self-hosted” no longer means the customer is alone with a repository.
The former co-founder’s argument identifies the failure mode: customers do not want the burden. Rising software and cloud costs identify the pressure: customers increasingly want control.
Both are true.
The opportunity is to separate ownership from toil.
When software runs where its economics and data require, while updates, policy, health and recovery arrive with managed-service ergonomics, self-hosting stops being a fringe identity. It becomes one deployment option inside a better product.
That may be what is waiting on the other side.

Sources

• Linux Foundation: The State of Open Source Software in 2025
• Linux Foundation: 2025 State of Tech Talent
• FinOps Foundation: State of FinOps 2026
• 37signals: Leaving the Cloud
• Opaque hybrid deployment architecture
• Confluent hybrid architecture
• GitLab Duo hybrid model configuration

← All writing