
July 15, 2026
6 min read
Why We Self-Host (Almost) Everything
Blue Monkey Makes
The default path for a new web studio is well-worn. Sign up for Vercel. Connect Contentful for the CMS. Add HubSpot for leads. Google Analytics for traffic. Sentry for errors. Maybe Datadog if you want logs. Each tool is excellent on its own. Each one is another $20-200/month subscription, another login, another vendor's terms of service, another dashboard that doesn't quite talk to the others.
Add it up and a small studio can easily spend $500-800/month on infrastructure tooling before writing a single line of client code. That felt wrong to us. Not because the tools are bad. They're good. But because for a studio of our size, the math doesn't work, and the trade-offs point in a different direction.
What we actually run
Our production infrastructure runs on a handful of servers we manage, at a fraction of what the same stack costs as stacked-up subscriptions. Here's what runs on them:
- Coolify: a self-hosted PaaS that handles deployments, SSL certificates, reverse proxying, and container management. It replaces Vercel, Heroku, and Render for our purposes.
- Directus: a self-hosted headless CMS we use for client projects where content management needs to be straightforward and extensible.
- Twenty: a self-hosted CRM. Open source, PostgreSQL-backed, with a REST API we can actually work with.
- Plausible CE: self-hosted, privacy-respecting analytics. No cookie banners, no consent flows, no sending visitor data to Google.
- GlitchTip: a self-hosted error tracking platform that speaks the Sentry protocol. Our apps use the standard Sentry SDKs and report to our own instance.
- Loki + Grafana + Promtail: a self-hosted logging stack. Promtail runs on each server, auto-discovers containers, and ships structured logs to Loki. Grafana gives us a query interface.
Everything deploys as Docker containers, and Coolify orchestrates most of it. The whole stack is reproducible: if a server disappeared tomorrow, we could rebuild it from configuration files.
What the numbers actually look like
The SaaS equivalent of our stack, at the tiers a small studio would realistically use:
- Vercel Pro: ~$20/month per project
- Contentful: ~$300/month (Team tier)
- HubSpot: ~$50-90/month (Starter CRM)
- Google Analytics: free, but the cost is your visitors' data
- Sentry: ~$26/month (Team tier)
- Datadog: ~$15-75/month depending on log volume
That's conservatively $500/month, and it climbs quickly with multiple projects or higher tiers. Our servers cost a small fraction of that. Coolify, Directus, Twenty, Plausible, GlitchTip, and the Loki stack are all open source: the software cost is zero.
Cost alone wouldn't have been enough to justify the setup time. The other benefits are what made it stick.
When something breaks, we know why
This is the less obvious advantage, and honestly the one that matters most day-to-day.
When a deployment fails in Coolify, we can read the build logs and trace the problem to its source, all the way down to the server. When a Directus migration doesn't apply cleanly, we can look at the PostgreSQL schema directly. When logs stop arriving, we can follow the pipeline end to end and see exactly where they stopped.
None of this requires opening a support ticket. None of it requires waiting for a vendor's status page to acknowledge an issue. None of it requires guessing whether the problem is on our side or theirs.
This isn't about being anti-vendor. It's about the compounding value of understanding your own infrastructure. Every issue we debug teaches us something about how the pieces fit together. Over time, that knowledge makes us faster, not just at fixing problems, but at designing systems that avoid them.
Everything shares a network
Self-hosted tools running on the same server, or on servers we control, can talk to each other directly. This sounds trivial until you've spent an afternoon configuring webhooks and API keys to connect two SaaS platforms that were never designed to work together.
Our API reaches the CRM without crossing the public internet, and a new service starts shipping its logs without any per-service setup.
When we needed to wire up a sales pipeline that creates CRM records from form submissions, sends nurture emails on a schedule, and logs every step, all of that happened inside our own network with tools we control. No middleware platform. No rate limits imposed by a third party.
The integration surface area is smaller, the latency is lower, and the failure modes are simpler. When everything is a container on a Docker network, "connecting two services" often means adding one environment variable.
Client data stays where we put it
We build sites and systems for small businesses, and we decide deliberately where their data lives. By default, that means servers we manage, backed up on a schedule we set.
The default isn't a rule. When a project fits a managed database better, like Supabase or MongoDB Atlas, we use one and choose its region and plan on purpose. Either way, the choice is made for the project, and we can tell a client exactly where their data sits and why.
Where we draw the line
We don't self-host everything. Some services are better left to specialists.
- Email delivery: We use Resend. Sending transactional and marketing email reliably at scale is a genuinely hard problem involving IP reputation, deliverability monitoring, bounce handling, and compliance. We have no interest in running a mail server.
- DNS: Cloudflare. DNS needs to be fast, globally distributed, and essentially never go down. Running our own nameservers would be foolish.
- CDN and DDoS protection: Cloudflare again, for some projects. Edge caching and attack mitigation are infrastructure problems best solved at scale.
The pattern: we self-host things where understanding the system makes us better at our work, and we outsource things where reliability requires infrastructure we can't reasonably operate.
The trade-offs are real
No solution comes without pain, and all we can do is pick the type of pain. Here is the pain we picked.
- Upgrades are manual. When Coolify releases a new version, we update it ourselves. When Directus ships a security patch, we apply it. Staying current requires attention and discipline.
- There's no support team. When something goes wrong at 10pm, the support team is us. Open source communities are generally helpful, but there's no SLA.
- Initial setup takes longer. Getting Twenty running with all four containers properly networked and domain-routed through Coolify took meaningfully more time than signing up for HubSpot. The payoff comes later, but the upfront investment is real.
- Server maintenance is a responsibility. Security updates, disk space, backup verification. These are ongoing practices, not one-time tasks.
What isn't on that list is quality. The open source tools we run are often the better product. Twenty is better documented than HubSpot and has the better interface, Coolify feels like a premium product, and Plausible is as good as analytics gets. The cost of self-hosting is running the software, not settling for worse software.
We're comfortable with these trade-offs because we're a technical studio. Infrastructure work is a natural extension of what we do. For a non-technical team, the calculation would be very different.
This isn't for everyone
A studio that doesn't enjoy infrastructure work should absolutely use managed services and focus on what they're good at. A team that needs enterprise-grade uptime guarantees should pay for them. A solo freelancer who wants to ship fast and not think about servers is well-served by Vercel and Contentful.
For us, self-hosting is a deliberate choice that aligns with how we want to work. We want to understand the full stack, not just the application code, but the deployment pipeline, the data layer, the logging, the error tracking, and the analytics. When a client asks how their data is stored, we want to answer from knowledge, not from a vendor's FAQ page.
We tried running our own LLM on that stack too. The Cheapest AI That Actually Works covers what we learned, and why the live features ended up on a cheap hosted model instead.
The servers cost us less per month than most teams spend on a single SaaS tool. The knowledge we've built by running them is worth considerably more than that.


