Replacing a $3000/mo Heroku Bill with a $55/mo Server

Idealist.org migrated their staging environments from Heroku to a single Hetzner server, cutting costs by 98% while enabling unlimited development environments.

The Problem: Staging Environment Costs

Idealist.org faced escalating costs for staging environments on Heroku. Each staging deployment required multiple dynos, managed databases, and add-ons, totaling approximately $500 per environment. With six environments needed for development and testing, monthly costs reached $3,000.

The team needed staging environments for:

Main development branch
Feature branches requiring stakeholder review
Individual developer testing
Quality assurance workflows

The Solution: Single Server Architecture

The team migrated to a Hetzner CCX33 dedicated server ($55/month) running Disco, an open-source Platform-as-a-Service tool. This single machine provides:

8 CPU cores
32 GB RAM
240 GB NVMe storage
Unlimited bandwidth

All six staging environments now run on this server with room to spare. Resource utilization remains under 10% CPU and 14 GB memory usage.

Implementation Details

Deployment Process

The new setup uses Docker containers managed by Disco’s deployment system. Each environment deploys automatically via GitHub webhooks, maintaining the same git-push workflow developers expect from Heroku.

Database Strategy

Instead of separate managed databases, all staging environments share a single PostgreSQL instance running directly on the server. This “good enough” approach works for non-production workloads while eliminating expensive database add-on costs.

SSL and Routing

Disco handles SSL certificate management and routing automatically. Each environment receives its own subdomain with valid HTTPS certificates.

Key Benefits

Cost Reduction: From $3,000/month to $55/month (98% savings)

Unlimited Environments: No longer constrained by per-environment costs

Faster Iteration: Teams can spin up environments for any branch without budget concerns

Simplified Management: Single server to monitor instead of multiple cloud services

Trade-offs and Considerations

Single Point of Failure: Unlike Heroku’s distributed infrastructure, this setup relies on one server

Manual Scaling: Vertical scaling requires server migration rather than clicking buttons

Operational Overhead: Team assumes responsibility for server monitoring, security updates, and maintenance

Geographic Limitations: Hetzner’s limited US presence affects latency for American users

Memory Management Best Practices

The discussion revealed important server optimization techniques:

OOM Prevention

Enable earlyoom or systemd-oomd for proactive memory management
Configure swap with zram for compressed memory overflow
Set appropriate vm.swappiness values (typically 1 for servers)

System Tuning

1
2
3
4
# Prevent system lockup during memory pressure
vm.overcommit_memory = 0
vm.overcommit_ratio = 0
vm.min_free_kbytes = 1024000

Process Priority Management

Adjust OOM scores to protect critical services:

1
2
echo -1000 > /proc/[pid]/oom_score_adj  # Protect important processes
echo 500 > /proc/[pid]/oom_score_adj    # Deprioritize memory-heavy processes

When Self-Hosting Makes Sense

This approach works best when:

Staging environments don’t require production-level reliability
Teams have basic Linux administration skills
Cost optimization outweighs convenience factors
Applications fit comfortably on single-server resources

Alternative Solutions

Several tools provide similar Heroku-like experiences on your own infrastructure:

Coolify: Web-based deployment platform
Dokku: Heroku-compatible PaaS
Kamal: Rails-focused deployment tool
CapRover: Container-based PaaS with GUI

The Bigger Picture

This migration represents a broader trend of companies reconsidering cloud costs as hardware capabilities increase. Modern servers offer exceptional price-performance ratios compared to managed platforms.

However, the decision involves more than pure cost calculations. Factor in:

Developer time spent on infrastructure
Risk tolerance for downtime
Team expertise with server management
Scaling requirements

For staging environments where 99% uptime suffices, self-hosting often delivers significant savings. Production workloads require more careful evaluation of the total cost of ownership.

Next Steps

If considering a similar migration:

Audit current usage: Identify which environments truly need managed platform features
Start small: Migrate non-critical environments first
Automate operations: Use configuration management tools like Ansible
Plan for growth: Design scaling strategies before you need them
Monitor closely: Implement proper alerting and backup procedures

The key insight isn’t that cloud platforms are inherently expensive, but that many workloads don’t require their full feature set. By matching infrastructure complexity to actual requirements, teams can achieve dramatic cost reductions while maintaining development velocity.

Signals

Replacing a $3000/mo Heroku bill with a $55/mo server