Self-hosting cost is not the server bill
The server is the cheap part. Self-hosting cost is the server plus the person who maintains it, plus the hours nobody logged, plus the outage you handle at 2am instead of emailing a vendor about. Teams compare a monthly subscription against a monthly instance price, see a large gap, and migrate — then rediscover the gap eighteen months later as salary.
That does not make self-hosting wrong. Open-source software genuinely wins on cost at scale, on data control, and on not being repriced by someone else's board. But the comparison only means something if both sides of it are complete.
Below is what the full line looks like, a break-even formula you can run on your own numbers, and the conditions under which running it yourself is the correct call.
The cost line items a subscription hides
A SaaS price bundles hosting, upgrades, security, backups, uptime and support into one number. Self-hosting unbundles all of it and hands each piece to you. None of the pieces disappear.
Compute, storage and network
The visible cost, and usually the smallest. You are paying for CPU, memory and storage sized for peak rather than average, plus egress, plus whatever redundancy you need. Cloud infrastructure prices change frequently at every provider, so build your model from their current pricing pages rather than from a number you read somewhere — including this page.
Size honestly. Most self-hosted deployments are provisioned for a load that never arrives, and over-provisioning is the quietest way to lose the cost argument before you have started.
The person
This is the real number. Somebody has to configure the stack, watch it, upgrade it, and be reachable when it breaks. Even a well-behaved deployment consumes several hours a month, and a bad week consumes a weekend. Multiply the hours by a fully loaded internal rate and you will usually find one engineer's partial attention costs more per year than the software you avoided paying for.
Ask a harder version of the question too: who is the second person? A stack only one employee understands is an availability risk and a retention hostage.
Security patching and access control
Vendor software gets patched without you noticing. Self-hosted open source technologies get patched when you patch them. That means tracking CVEs for every component in the stack, scheduling maintenance windows, and owning authentication, secrets and network boundaries yourself.
This is the line item that most often goes to zero on the spreadsheet and to a serious number in reality, because the cost of not doing it is not a cost until the day it is all of them.
Backup, recovery and continuity
Backups you have never restored are not backups. Budget storage for real retention, plus the quarterly hour to test a restore, plus a documented recovery path. Managed services amortize this across thousands of customers; you amortize it across one.
Downtime
Put a number on an hour of the system being unavailable — people idled plus work not done plus customers not served. High availability across two nodes roughly doubles the infrastructure line, so the honest question is whether your downtime cost per hour justifies that. For plenty of internal tools it does not, and single-node with good backups is the rational choice.
What open source deployment actually involves
The deployment work itself is the part people underestimate least often and still underestimate. A typical self-hosted stack means containerizing the application with Docker, standing it up on a host or on Kubernetes if you need orchestration, wiring a database and object storage, terminating TLS, and putting monitoring and log aggregation in front of all of it.
Then comes the part that has nothing to do with the software: integration with the systems you already run. Single sign-on, your identity provider, your existing databases, your alerting, and any workflow that has to cross between them. Each integration is a small project, and together they usually take longer than the initial deploy.
If you are moving off a hosted plan, add the migration itself — export, transform, import, verify, and a cutover window where both run in parallel. Plan to migrate once, properly, rather than discovering halfway that a data type does not map. Our breakdown of n8n cloud versus self-hosted walks through a concrete version of this trade-off on one specific tool.
Self-hosting an LLM: the GPU reality
Running an open source model locally has a different cost shape from running an application. A GPU capable of serving a useful model at reasonable latency is a real capital purchase or a per-hour rental that bills whether or not anyone is using it, and idle GPU time is the single biggest waste in self-hosted AI.
Utilization decides everything. API pricing is per token, so it costs nothing when idle. Self-hosted inference costs the same at 5% utilization as at 95%. Below a genuinely high, steady request volume, the API is cheaper — often by a wide margin — and the sensible reasons to self-host anyway are data residency, privacy, and independence from a vendor's rate limits.
We cover the hardware side in detail in the local LLM cost and hardware guide, and which models are worth running in the best open source LLMs for business. Both change fast, so check the dates on any figures you rely on.
Where you run it: public cloud, private cloud or bare metal
Three options, three different cost curves. Public cloud virtual machines are fastest to start and most flexible, and the most expensive per unit of sustained compute — you are renting elasticity you may not use. Private cloud or your own bare metal is cheapest per unit at steady load and carries capital cost, capacity planning and hardware failure as your problem. Hybrid cloud splits the difference, keeping regulated data on infrastructure you own and bursting elsewhere.
Pick by load shape rather than by preference. Spiky, unpredictable demand belongs on cloud services you can scale down. Flat, predictable demand — which most internal systems have — is where owned hardware or a long-term reserved instance wins, and where the self-hosting argument is strongest.
Whichever you choose, the operating system, the patch cadence and the recovery plan come with it. That is the part that does not change between hosting models, and it is the part that costs money every month.
A break-even formula you can run today
Annual self-hosted cost = (server, storage and network per month x 12) + (maintenance hours per month x fully loaded internal rate x 12) + setup and migration cost amortized over your expected life of the system + backup storage + security and patching hours + expected downtime cost.
Annual SaaS cost = (seats x price x 12) + overage + the integration work you would still do either way.
Compare those two. Then divide the one-off setup and migration cost by the monthly difference to get the number of months before self-hosting is actually ahead. If that number is longer than you expect to keep the system, or longer than the tenure of the person maintaining it, the migration loses even when the monthly figure looks better.
Run it again at three times your current usage. Self-hosting improves as you scale, because the marginal user is nearly free, while per-seat pricing does not. If self-hosting only wins at a volume you may never reach, wait.
When self-hosting genuinely wins
You already have the skill and the on-call. If a platform team exists and is already running Kubernetes, the marginal cost of one more service is small. This is the single strongest predictor of a good outcome.
Per-seat pricing at scale. Cross a few hundred users and most subscription models get expensive faster than infrastructure does.
Data that cannot leave. Regulatory, contractual or client-imposed constraints make self-hosting a requirement rather than an optimization, and then the cost comparison is beside the point.
Vendor lock-in you want out of. Owning the deployment means owning the exit. Open source software you host can be moved between cloud providers or brought on-premises without renegotiating anything.
The benefits beyond cost savings are often the real reason: control over versions, no forced upgrades, no surprise repricing, and the ability to modify the source when you need behavior the vendor will not build.
When it does not
Small teams with no dedicated infrastructure person. Spiky or low utilization. Anything where a few hours of downtime costs more than a year of subscription. Any tool that is not core to what you do — self-host the thing that differentiates you, buy the rest.
There is a middle path that most teams skip past: managed hosting of open source software. You keep the license freedom and portability, and someone else takes patching and uptime. It costs more than raw infrastructure and less than the fully loaded self-hosted number, and for a lot of businesses it is the correct answer.
If you want help deciding rather than a vendor pitch, our AI consulting practice does open source consulting alongside automation work and will run this comparison with you. The free three-minute audit at /free-audit will tell you where your manual work and running costs actually sit before you make an infrastructure decision on top of them.
Frequently asked questions
Is self-hosting cheaper than SaaS?
Sometimes, and almost never as much cheaper as the server price suggests. Self-hosting wins at high user counts, at steady high utilization, and where you already employ people who run infrastructure. It loses for small teams, spiky workloads and anything where downtime is expensive, because the maintenance and on-call cost does not scale down.
What is open source deployment?
It is the work of taking open source software and running it on infrastructure you control: containerizing it, provisioning compute and storage, configuring networking and TLS, connecting a database, adding monitoring and backups, and integrating it with your identity and alerting systems. Docker handles packaging and Kubernetes handles orchestration when you need to scale across nodes.
What hidden costs should I include in a self-hosting estimate?
Maintenance hours at a fully loaded rate, security patching, backup storage plus restore testing, monitoring, the one-off setup and migration effort, expected downtime cost, and the cost of a second person who can cover the stack. Those six lines are usually larger in total than the compute bill.
Do I need Kubernetes to self-host?
Usually not. A single host running Docker with good backups covers most internal applications and is far cheaper to operate. It earns its complexity when you need multi-node high availability, automatic scaling or many services managed by one platform team, and it is an expensive default for anything smaller.
Is it cheaper to self-host an LLM than to use an API?
Only at consistently high volume. API pricing is per token and costs nothing when idle, while a GPU costs the same whether it is busy or not. Below steady heavy usage the API wins on cost, and the good reasons to self-host anyway are privacy, data residency and independence from vendor limits rather than the monthly bill.
How do I calculate the break-even point?
Divide your one-off setup and migration cost by the monthly difference between the fully loaded self-hosted cost and the subscription cost. That gives months to break even. If it exceeds the time you expect to keep the system running, staying on the hosted product is the cheaper decision.