Managed vs Self-Hosted Dev Tools: When to Stop Running Your Own Infrastructure

The Self-Host Ideology Problem

Technical communities treat self-hosting as inherently more professional. Running your own GitLab instance, Kubernetes cluster, and mail server gets celebrated as a mark of engineering depth.

That's a reasonable position when the goal is learning. If you want to understand how PostgreSQL B-tree indexes work or how to secure a container registry, self-hosting is the only path. But if your goal is to ship an application, every hour spent troubleshooting a GitLab runner update is an hour not spent building the thing you're trying to build.

The question is never "can I self-host this?" It's: should the infrastructure be the work, or should the application be the work?

Tools Worth Managed Treatment

At small-to-medium scale, these four categories are almost always better handled by a managed provider.

Databases (PostgreSQL, MySQL)

Managed database services handle the three operational tasks that consume disproportionate time: automated backups, point-in-time recovery, and high-availability replication. A $15/month managed database is significantly cheaper than the labor cost of recovering a corrupted database at 3am — not to mention the data loss risk if your backup strategy wasn't tested.

CI/CD Runners

GitHub Actions and GitLab CI managed runners are operationally invisible. You don't patch the OS, manage disk space, or troubleshoot dependency conflicts on the runner itself. The compute spins up, runs your workflow, and disappears. At small-team scale, the managed cost is almost always lower than the maintenance overhead of self-hosted runners.

Code Repository

Unless you have air-gapped requirements or extreme data sovereignty needs, GitHub or GitLab SaaS is the standard. Self-hosted GitLab CE requires substantial RAM (minimum 4GB, comfortable at 8GB+), constant patching, and you own the backup strategy.

Container Registry

GitHub Container Registry or Docker Hub handles storage management and garbage collection for stale images. Self-hosting a registry (Harbor, etc.) introduces its own operational overhead — storage quotas, cleanup policies, access control — that isn't justified at small-team scale.

SiteGround — Managed WordPress with Staging →

Tools Worth Self-Hosting

The calculation flips in specific scenarios.

The application runtime. Your core product — the Node.js API, the Python worker, the application service — should run on infrastructure you control. Environment variables, resource allocation, and deployment configuration are your operational domain.

The development VPS. The environment where you actively break things must be self-managed. You cannot develop operational instinct through a managed abstraction. Breaking a configuration and recovering it is the learning mechanism.

Compliance and air-gapped requirements. HIPAA, financial data regulations, or any requirement that data cannot touch multi-tenant cloud infrastructure — self-host the full pipeline. This is a requirement, not a preference.

The scale pivot. When your GitHub Actions bill crosses $50/month or a managed database costs more than a VPS that could host it directly, the managed tax is high enough to justify the operational overhead. Run the math at that point.

The Decision Framework

Is the tooling itself the learning goal?
  Yes → Self-host.
  No → Continue.

Do you have legal, compliance, or air-gap requirements?
  Yes → Self-host.
  No → Continue.

Does managed cost exceed comparable self-hosted cost by 3x or more?
  Yes → Evaluate self-hosting.
  No → Stay managed.

Are you spending more than 2 hours/month maintaining this tool?
  Yes → Switch to managed.
  No → Self-host is fine.

The Hybrid Pattern

The most practical approach for most operators is a deliberate split.

Managed (outsource the headaches): Code repository, CI/CD runners, production database, container registry, global CDN. These are high-stakes, low-differentiation infrastructure. Getting them wrong is expensive; getting them right doesn't advance your product.

Self-hosted (maintain control): Development VPS, staging environments, the application deployment target. This is where operational learning happens and where your product actually runs.

This pattern directs your operational effort toward the infrastructure that is your product — and outsources the operational overhead of the plumbing that supports it.

For the full lab architecture: How to Lab the Full Stack Without Buying Hardware (What Goes Where)

FAQ

Is self-hosting a database on a VPS reliable enough for production? Only with a tested backup and recovery strategy. Running PostgreSQL without WAL archiving or verified restore procedures means one disk failure away from significant data loss. For most small teams, a managed database at $15/month is the correct answer — not because self-hosting is impossible, but because the risk management overhead of doing it correctly typically exceeds the cost.

What's the actual cost difference between managed and self-hosted at small scale? A VPS to self-host a database might cost $6/month. A managed database might cost $15/month. The $9 difference is the managed premium. If you spend more than 15 minutes per month thinking about that database — backups, updates, monitoring — the managed option is already cheaper when you value your time.

Does self-hosting improve security or create more attack surface? It typically creates more attack surface. Managed providers dedicate engineering teams to OS patching and service hardening. When you self-host, that team is you. If you aren't applying patches on a regular cycle, you are likely less secure than the equivalent managed provider — not more.

Related:

• How to Lab the Full Dev Stack Without Buying Hardware
• How to Lab the Full Stack Without Buying Hardware (What Goes Where)
• You Don't Need to Be a Developer — But You Need to Understand the Stack
• What Is a CI/CD Pipeline? (Explained for Infrastructure People)

SiteGround — Managed WordPress with Staging →