Why We Self-Host (Almost) Everything

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 lives on a few Hetzner VPS instances. The total hosting cost is roughly $30-50/month. 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 it for our own site and 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. Coolify orchestrates most of it. Promtail discovers new containers automatically through Docker labels. The whole thing is reproducible — if a server disappeared tomorrow, we could rebuild the stack from compose files and environment variables.

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 Hetzner servers cost roughly $40/month total. 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, SSH into the server, inspect the container, and trace the problem to its source. When a Directus migration doesn't apply cleanly, we can look at the PostgreSQL schema directly. When Promtail stops shipping logs, we check its config and Docker socket permissions.

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 NestJS API talks to Directus over the internal Docker network. Twenty's REST API is accessible from our API without traversing the public internet. Promtail discovers every container on the host automatically and starts shipping its logs to Loki without per-service configuration.

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. Their customer data, analytics, form submissions, and CRM records live on servers we control, hosted with providers we chose, in jurisdictions we understand.

This isn't a dramatic privacy statement. It's a practical one. We don't have to read a SaaS vendor's data processing agreement to know where client data goes. The data sits in PostgreSQL on a Hetzner VPS, backed up on a schedule we set.

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

It would be misleading to present self-hosting as a clean win.

• 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.
• Some tools are less polished. Self-hosted open source alternatives are rarely as smooth as their SaaS equivalents. The documentation may be thinner. The UI may be rougher.

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.

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.