At Disco, we help teams escape expensive PaaS pricing while keeping the developer experience they love. This is the story of how Idealist.org, the world’s largest nonprofit job board, tackled a common and expensive challenge: the rising cost of staging environments on Heroku.

To give a sense of scale, the site handles millions of monthly visitors with a substantial, multi-gigabyte Postgres database.

The Problem: The $500 Staging Environment

For any busy site like Idealist.org, staging environments that faithfully replicate the production tech stack are critical for testing. But on Heroku, this safety came at a steep price. A single staging environment, running web and worker dynos alongside the necessary add-ons to meet the site’s technical requirements, cost their team roughly $500 per month.

This meant having just two permanent environments (dev and main) was already a $1k/month commitment. The fundamental issue wasn’t the size of the dynos, it was Heroku’s pricing model. You pay per environment. Even with “right-sized” dynos, running multiple distinct applications, each with its own web process, worker process, and database add-on, would remain expensive.

The Experiment: A Single Server

When faced with an expensive enterprise contract renewal, the Idealist team decided to test an alternative. The hypothesis was simple: could they move just one environment to cheaper hardware to relieve some cost pressure?

They provisioned a standard Hetzner CCX33 server ($55/month) and used Disco to replicate their git push to deploy workflow on the new machine. Critically, all staging environments would share a single “good enough” Postgres instance directly on the server, eliminating the need for expensive managed database add-ons that, on Heroku, often cost more than the dynos themselves.

For staging and testing purposes, this approach proved ideal: developers get isolated databases that reset cleanly, without the complexity or cost of managed database services designed for production workloads.

Bridging the Gap: Why Not Just Docker Compose?

At this point, a fair question is: why use a tool like Disco instead of just docker-compose up on a server? Disco bridged the gap between a raw VPS and a true PaaS experience. Specifically, it provided:

• The git push to deploy workflow, just like Heroku.
• Automated, zero-downtime deployments for every push.
• Automatic SSL certificate generation and renewal for all branch URLs.
• A simple web UI to see logs and manage all environments in one place.

Essentially, it saved the team from writing and maintaining their own deployment automation.

The “Staging Explosion”

Because Disco made the process so simple, the experiment was a success and adding subsequent environments was trivial. Soon, that one server was running:

• An environment for the main branch
• An environment for feature-freeze
• A “throwaway” environment for random PRs
• Long-running environments for major features

In total, 6 full staging environments were now running comfortably on that single machine. The calculation was simple: 6 environments × $500/month on Heroku totals a $3,000/month liability.

Even with all 6 environments and other projects running, the server’s resource usage remained low. The average CPU load stayed under 10%, and memory usage sat at just ~14 GB of the available 32 GB.

The Trade-Offs & Realities

Of course, the migration wasn’t a magic bullet. There were new, real-world problems to solve.

Each new staging environment still required DNS and CDN configuration - not difficult, but not automatic either. The team also took on responsibility for server monitoring, security updates, and handling any infrastructure issues themselves - operational overhead that Heroku had previously covered. And while Hetzner’s price-performance is exceptional, its limited presence in the US was a consideration; for this staging workload, it wasn’t an issue, but it’s a factor for production services targeting US users.

For staging environments specifically, the team accepted that a server failure would require reprovisioning, trading Heroku’s redundancy for dramatic cost savings on non-critical workloads. The main technical hurdle was adapting the application’s networking to work within Docker’s container model, which took about a day of an engineer’s time to resolve.

The Real Insight: Staging Became a Free Commodity

Six months in, the experiment has become permanent infrastructure. The biggest benefit wasn’t just the savings, it was the change in the team’s mindset. Staging environments went from being a scarce, expensive resource to an abundant, disposable commodity. Any developer could spin up an environment for a pull request without asking for permission or worrying about cost.

They learned that the real cost of their PaaS wasn’t just the money; it was the hesitation.