When to Self-Host
Managed services are the right default for early-stage startups. But there is a tipping point where the cost of managed services exceeds the cost of self-hosting, including your time to manage the infrastructure. Knowing when that tipping point arrives — and when to ignore it — is the difference between smart infrastructure investment and premature ops work.
The short version: self-hosting before you are spending $500-1,000 per month on a managed service is almost always premature. The exception is when your product is infrastructure itself.
The Tipping Point
The cost equation:
Managed service cost per month
vs
Self-hosting cost per month + (engineering hours * hourly rate)
Example: Managed database
Managed (e.g., RDS, Neon Pro, Supabase Pro): $50/month
Self-hosted on VPS: $20/month
Engineering time for maintenance: ~4 hours/month
Engineering hourly value: $100/hour (conservative for a startup)
True self-hosted cost: $20 + (4 * $100) = $420/month
Decision: Keep managed. The $50 service is 8x cheaper than
self-hosting when you account for time.
Same example at scale:
Managed: $800/month
Self-hosted on VPS: $100/month
Engineering time: ~4 hours/month (same, because you've automated)
True self-hosted cost: $100 + (4 * $100) = $500/month
Decision: Self-hosting is now cheaper. Consider the switch.
The key insight: the engineering time component stays roughly constant (or decreases as you automate), while the managed service cost scales with usage. At some point the lines cross. That crossover point is usually between 1,000 per month for the managed service.
What People Self-Host Too Early
Services that startups self-host prematurely:
Databases:
"Managed Postgres is $25/month, I can run it on a $5 VPS"
→ You can, until the disk fills up on Saturday night and you
lose data. The $25 buys automated backups, monitoring, and
point-in-time recovery. That's a bargain.
Email:
"Running my own SMTP server saves money"
→ Your emails will land in spam. Email deliverability is a
specialized problem. Resend, Postmark, and SendGrid have
spent years building sender reputation. You have not.
Search:
"I'll run Elasticsearch on a VPS"
→ Elasticsearch is a resource hog that requires tuning,
monitoring, and regular maintenance. Use Meilisearch Cloud
or Algolia until search is a core differentiator.
CI/CD:
"I'll set up Jenkins instead of paying for CI"
→ Jenkins requires a server, maintenance, plugin updates,
and security patches. GitHub Actions is free for 2,000
minutes/month. Use it.
Monitoring:
"I'll run Grafana and Prometheus myself"
→ This is ops work to monitor your ops work. Use Betterstack,
Datadog free tier, or Grafana Cloud free tier.
What Is Worth Self-Hosting Early
Some services are worth self-hosting even at small scale, because the managed versions are expensive relative to the simplicity of running them yourself:
Reasonable early self-hosting:
Plausible Analytics:
Managed: $9/month
Self-hosted: Free, runs in a Docker container, minimal maintenance
Effort: 30 minutes to set up, ~0 maintenance
Verdict: Worth self-hosting if you are comfortable with Docker
Umami Analytics:
Same situation as Plausible
n8n or Windmill (workflow automation):
Managed: $20+/month
Self-hosted: Free, Docker container
Effort: 1 hour to set up
Verdict: Worth self-hosting for light usage
Uptime Kuma (monitoring):
Managed alternatives: $10-20/month
Self-hosted: Free, single Docker container
Effort: 15 minutes to set up
Verdict: Worth it, but do not use it to monitor the same server it runs on
Ghostfolio, Memos, or other personal/internal tools:
Low stakes if they go down. Good self-hosting candidates.
The common theme: stateless or low-state applications that run in a single container, require minimal configuration, and where downtime is not customer-facing.
The $500-1,000 Threshold
When a managed service bill hits $500-1,000 per month, it is time to evaluate self-hosting seriously.
Self-hosting evaluation checklist:
1. What is the current monthly cost? ___
2. What would hosting cost be on bare infrastructure? ___
3. How many engineering hours per month for maintenance? ___
4. Do we have someone with the skills to manage this? ___
5. What is the blast radius if self-hosted version goes down? ___
6. How complex is the migration from managed to self-hosted? ___
7. Will self-hosting require on-call rotations? ___
If (2) + engineering cost < (1) by at least 30%:
Consider self-hosting.
If you don't have someone skilled in managing this:
Stay managed until you hire someone who is.
If downtime costs more than the managed service:
Stay managed.
Common Crossover Candidates
Database (Postgres, MySQL):
Managed cost before crossover: $200-500/month (RDS, Cloud SQL)
Self-hosted cost: $50-100/month (dedicated server)
Skills needed: Backup management, replication, monitoring, tuning
Risk: Data loss, downtime
Verdict: Self-host only when you have a dedicated ops person or
strong automation. Never wing it.
Redis/Valkey:
Managed cost before crossover: $100-300/month (ElastiCache, Upstash paid)
Self-hosted cost: $10-20/month
Skills needed: Minimal — Redis is simple to operate
Risk: Low — usually used as cache, not primary data store
Verdict: One of the safer things to self-host early
Object storage:
Managed (S3): Scales with usage, rarely hits $500/month early
Self-hosted (MinIO): Free, S3-compatible
Verdict: Stay on S3 or R2. The cost is low and the reliability
is worth it. Self-host only for compliance reasons.
Search (Elasticsearch, Meilisearch):
Managed: $50-500/month depending on provider and index size
Self-hosted: Complex to operate, resource-intensive
Verdict: Self-host only if search is a core product feature
and you need deep customization
The Infrastructure Product Exception
If your product IS infrastructure, self-hosting is not premature ops work — it is product development. This is the one exception to the "don't self-host early" rule.
If you are building:
- A database product → You need to run databases
- A deployment platform → You need to manage servers
- A monitoring tool → You need your own monitoring stack
- A security product → You need to run security infrastructure
- An analytics platform → You need to process data at scale
In these cases, self-hosting is R&D, not ops overhead.
The skills you build running the infrastructure ARE your product.
Fly.io self-hosts everything because they ARE the hosting platform. Supabase self-hosts Postgres because that is their core product. These companies do not have a choice — their product requires deep infrastructure expertise.
Migration from Managed to Self-Hosted
When you do decide to self-host, plan the migration carefully:
Migration steps:
1. Set up the self-hosted version alongside the managed version
2. Mirror traffic or data to the self-hosted version
3. Verify parity: same performance, same behavior, same data
4. Set up monitoring and alerting for the self-hosted version
5. Switch traffic gradually (10%, 50%, 100%)
6. Keep the managed version running for 2 weeks as fallback
7. Decommission the managed version
Do NOT:
- Switch over in one step with no fallback
- Migrate on a Friday
- Skip the monitoring setup
- Assume self-hosted behavior is identical to managed
Automation Requirements
If you are going to self-host, automate everything from day one:
Self-hosting automation checklist:
□ Automated provisioning (Terraform, Pulumi, or scripts)
□ Automated backups with verified restores
□ Automated security updates
□ Automated monitoring and alerting
□ Automated failover (if applicable)
□ Automated scaling (if applicable)
□ Runbook for common operations
□ Runbook for disaster recovery
If you cannot automate these within the first week, you are not ready to self-host. Manual operations do not scale and create bus factor problems.
The Hybrid Approach
You do not have to go all-in on either managed or self-hosted. Most mature startups use a mix:
Typical hybrid setup:
Managed:
- Primary database (too critical to risk)
- Email sending (deliverability is specialized)
- Authentication (security is specialized)
- CDN and DNS (Cloudflare, no reason to self-host)
Self-hosted:
- Application servers (commodity, easy to manage)
- Redis cache (simple to operate, low risk)
- Background job workers (stateless, easy to replace)
- Internal tools (low stakes if they go down)
- Analytics (if privacy requirements demand it)
This approach lets you self-host the easy, low-risk components while keeping the critical, complex ones managed.
Common Pitfalls
- **Self-hosting to save 20/month. Do not self-host until the managed service costs hundreds per month.
- Self-hosting without automation. Manual backups, manual deploys, manual monitoring. One missed backup and one disk failure is a company-ending event. Automate or stay managed.
- Self-hosting critical services without on-call. If your self-hosted database goes down at 2am and nobody notices until 8am, that is six hours of downtime. Managed services have 24/7 ops teams. You need equivalent coverage if you replace them.
- Underestimating the maintenance burden. Setting up a service takes a day. Maintaining it takes hours every month, forever. The initial setup cost is the smallest cost.
- Self-hosting email. Just do not. Email deliverability is a specialized domain with IP reputation, SPF, DKIM, DMARC, feedback loops, and blocklists. Use a service.
- Not planning the migration back. Sometimes self-hosting does not work out. If you cannot migrate back to managed quickly, you are stuck maintaining something that is not working.
Key Takeaways
- The tipping point for self-hosting is usually $500-1,000/month in managed service costs. Below that, the engineering time to maintain self-hosted infrastructure costs more than the service itself.
- Self-hosting before the tipping point is premature ops work that takes time away from building your product. The exception is when your product IS infrastructure.
- When you do self-host, automate everything: provisioning, backups, monitoring, security updates, and failover. Manual operations create fragility and bus factor problems.
- Use a hybrid approach: self-host the simple, low-risk components (Redis, background workers, internal tools) while keeping critical services (database, auth, email) managed.
- Always plan the migration back. If self-hosting does not work out, you need a path to return to managed without an emergency.