You're (maybe) not saving money. You're hiding the cost in your engineers' calendars.
Introduction: Free as in Beer, Free as in Puppy
Every few months, someone on LinkedIn drops the classic take: "Why are you paying for X when Y is open source and free?"
Free Prometheus. Free Grafana. Free Vault. Free ArgoCD. Free everything.
There's an old saying in the open source world that newer engineers seem to have never encountered: "Free as in speech, not free as in beer." Richard Stallman coined this distinction decades ago to explain that "free software" is about freedom: The freedom to run, study, modify, and distribute the code, not about price. The software is free as in liberty, not as in someone is handing you a free drink at a bar.
But somewhere along the way, the industry collectively forgot this. We started treating open source tools as if they were free beer. Download it, deploy it, done. No bill, no problem.
Here's the thing: even the original metaphor doesn't go far enough for what happens in production. Open source infrastructure tooling isn't "free as in beer" and it's not just "free as in speech." It's free as in puppy. Someone hands you this amazing thing at no upfront cost, and it's genuinely wonderful, but now you have to feed it, walk it, take it to the vet, clean up after it, and rearrange your entire life around it. And if you neglect it, it WILL destroy your couch at 3 AM.
That 3 AM? It's the PagerDuty alert because Prometheus ran out of memory after a cardinality explosion. The two sprints your team spent figuring out Vault auto-unseal after a cluster migration (I have a nice article about it, by the way!). The senior SRE who spends 30% of their time babysitting Grafana dashboards instead of building the internal platform your developers are begging for.
I've been running open source infrastructure tooling in production for years, across Azure, Kubernetes, and hybrid setups. I love open source. I contribute to it. I believe in the freedom part wholeheartedly. But I'm tired of the industry pretending that the freedom part means the cost part is zero.
Let's break down what you're actually paying for.
The Licensing Illusion
When someone says "Prometheus is free," what they mean is: "There is no licensing fee."
That's it. That's the entire truth of that statement. Everything else (compute, storage, networking, human hours, context switching, on-call burden, upgrades, security patching) is very much not free.
Here's a mental model that helps: the license is the cheapest part of any production software. Always has been. Whether you're running a commercial product or an open source one, the cost of operating it dwarfs the sticker price.
The difference with open source is that there IS no sticker price, which makes people wildly underestimate the total cost. When your company pays $50,000/year for a managed service, that number lives in a spreadsheet somewhere. Finance sees it. Leadership questions it. Somebody has to justify it every year.
But when three SREs each spend 15% of their week maintaining the self-hosted Prometheus + Thanos + Grafana stack? That cost is invisible. It doesn't show up in any line item. It's buried inside salaries that were already budgeted for "infrastructure work."
Where the Money Actually Goes
Let me walk you through the cost categories that open source evangelists conveniently forget to mention.
1. Infrastructure Costs (The Obvious One)
This is the one people at least acknowledge. You need servers, whether VMs or Kubernetes nodes, with enough CPU, memory, and disk to run your tooling. For a mid-sized Prometheus deployment monitoring a few hundred microservices, you're looking at dedicated nodes with 16-64GB of RAM just for the metrics stack. Add Loki for logs, Tempo for traces, and you need even more.
A realistic self-hosted observability stack for a mid-sized company runs $2,000–$5,000/month in raw infrastructure costs alone, depending on your cloud provider and data volume.
2. Engineering Time (The Expensive One)
This is the big one, and it's the one nobody wants to quantify.
Setting up Prometheus is straightforward. Running Prometheus in production at scale is a full-time job. You'll deal with:
- High cardinality management: One bad metric label and your Prometheus instance eats 80GB of RAM overnight. Production estimates suggest around 3-8KB of RAM per active series, and a mid-sized company can easily hit 10 million active series.
- Storage and retention: You need to figure out long-term storage. Thanos? Cortex? Mimir? Each one is another system to operate.
- Upgrades: Every major version bump is a project. You need to test it, stage it, roll it out, and hope nothing breaks.
- Federation and sharding: As you scale, a single Prometheus instance won't cut it. Now you're designing a distributed system.
Senior SRE salaries in Europe and the US easily exceed $100,000-$150,000/year. If you have one engineer spending just 20% of their time on observability stack maintenance, that's $20,000-$30,000/year in hidden operational costs. For a single tool in your stack.
Now multiply that across Vault, ArgoCD, cert-manager, external-dns and whatever else you're self-hosting. The number gets uncomfortable fast.
3. Opportunity Cost (The Invisible One)
This is the one that should keep engineering leaders up at night.
Every hour your SRE team spends upgrading Grafana, troubleshooting Loki ingestion failures, or debugging Vault token renewal issues is an hour they're NOT spending on:
- Building golden paths for developers
- Improving deployment pipelines
- Reducing incident response times
- Working on the internal platform your developers actually need
I've seen teams with 4-5 SREs where 2 of them are effectively full-time infrastructure janitors for their open source stack. That's not an engineering team. That's a managed service provider that charges $300K/year and only has one customer.
4. Knowledge Concentration Risk
When you self-host, the operational knowledge lives in people's heads. Usually one or two people's heads.
What happens when your Vault expert goes on paternity leave and the auto-unseal token expires? What happens when your Prometheus wizard changes companies and nobody else understands the recording rules or the Thanos compactor config?
I've seen this movie play out more times than I can count. The knowledge walks out the door, and the team spends months reverse-engineering their own infrastructure.
5. Security and Compliance Overhead
Open source software doesn't patch itself. When a CVE drops for Grafana (and they drop regularly, don't believe me? Check it out here), YOU are responsible for:
- Assessing the impact
- Testing the patch
- Rolling it out across all environments
- Documenting the process for your compliance team
With a managed service, this is someone else's problem. With self-hosted, it's your 4 PM on a Friday problem.
Grafana Labs itself shifted core projects to the AGPLv3 license, which means enterprises in regulated industries (finance, healthcare, government) often end up needing the Enterprise license anyway for security features like SAML/LDAP and data source permissions. So much for "free."
The Break-Even Calculation Nobody Does
Here's a framework I use when teams ask me "should we self-host or use managed?"
Total Cost of Self-Hosting (Annual):
- Infrastructure: VMs/nodes, storage, networking
- Engineering labor: Hours spent on setup, maintenance, upgrades, troubleshooting × loaded hourly rate
- On-call burden: Additional compensation or rotation overhead for infrastructure-specific incidents
- Training: Onboarding new team members on the custom setup
- Incident cost: Time spent on self-inflicted outages caused by the tooling itself
Total Cost of Managed Service (Annual):
- Subscription or usage-based fee
- Integration/migration effort (one-time, amortized)
- Reduced flexibility tax: workarounds for features the managed service doesn't support
If your self-hosting total exceeds the managed service by 20% or more, you're paying a premium to have worse reliability and more operational burden. And in my experience, for teams under 10 SREs, the self-hosted option almost always loses this calculation.
When Self-Hosting Actually Makes Sense
I'm not saying you should never self-host. There are legitimate reasons:
Data sovereignty is non-negotiable. If your compliance team says observability data cannot leave your network, self-hosting might be your only option. This is real in healthcare, finance, and government, not a hypothetical.
You're at hyperscale. If you're processing billions of samples per day, the cost curves flip. At massive volume, managed services get expensive fast (AWS Managed Prometheus at $0.03 per million samples adds up). If you have the team to support it, self-hosting at this scale can make economic sense.
The tool IS your product. If you're building a platform team that sells internal infrastructure as a service to your organization, deep expertise in the underlying tools is a competitive advantage, not a cost center.
You need deep customization. Custom scrape intervals, unique retention policies, integration with legacy systems. Sometimes the managed service just can't do what you need.
But for the vast majority of companies (startups, mid-size companies, even large enterprises with lean SRE teams) the "free" open source stack is more expensive than the managed alternative once you factor in all costs.
A Practical Decision Framework
Before you self-host your next open source tool, answer these questions honestly:
Do we have at least two people who deeply understand this tool? If the answer is one (or zero), you're building a single point of failure into your infrastructure.
Can we quantify the engineering time this will require? If you can't put a number on it, you're already in trouble. Track it for a month. You'll be surprised.
What's the managed alternative's actual cost? Not the sticker shock number on the pricing page. The real number after you account for the engineering time you'd reclaim.
Is operating this tool a strategic differentiator? If operating Prometheus doesn't make your product better or your customers happier, it's overhead. Treat it like overhead.
What's our exit cost? If you self-host for two years and then decide to migrate to managed, what's that migration going to cost? Factor it in upfront.
The Uncomfortable Truth
The infrastructure community has a cultural bias toward self-hosting. We celebrate it. We write blog posts about our "fully open source stack." We look down on teams that "just pay for Datadog."
But engineering leadership isn't about ideology. It's about making smart trade-offs with limited resources. And spending $300K/year in hidden engineering costs to avoid a $60K/year managed service bill isn't smart. It's pride disguised as engineering.
Open source is incredible. I use it every day. I've built my career on it. But the next time someone tells you their monitoring stack is "free," ask them one question:
"How much time does your team spend operating it?"
Watch how fast the conversation changes.
What's your experience with self-hosted vs managed tooling? Have you ever calculated the real cost? I'd love to hear your stories in the comments.
Top comments (0)