Heroku Bill Climbing? 7 Alternatives for a Rails App With Postgres and Worker Dynos

If you run a small Rails app on Heroku - one web process, a couple of Sidekiq worker dynos, a Postgres add-on, Redis for the queues - and the bill has crept past a few hundred dollars a month, the closest like-for-like replacements are Render, Railway, and Fly.io. All three run a web service and separate worker services from the same repo, all three give you a managed Postgres, and all three come in meaningfully cheaper than the equivalent Heroku Standard dynos plus a Heroku Postgres Standard plan. If you are cost-obsessed and have someone who genuinely enjoys ops, Kamal 2 on a Hetzner box is the cheapest in raw dollars. And before you migrate anything, right-size your Postgres and kill your idle staging apps - that alone routinely cuts a small bill by a third with zero risk.

I have watched a lot of Rails teams hit this exact wall. Ruby still powers about 7% of the web whose server language is known, and a large share of those apps grew up on Heroku. Here is the honest breakdown of where the money goes and where it should go instead.

Key takeaways

• For a small Rails app (1 web process, 2 Sidekiq workers, ~25GB Postgres, Redis, 1 staging environment), the closest like-for-like replacements are Render, Railway, and Fly.io. All three run a web service and separate worker services from one repo, and all three undercut the equivalent Heroku Standard dynos plus a Heroku Postgres Standard plan. Verify each figure against the vendor pricing pages linked below (list prices checked September 2026).
• The biggest line item on almost every small Heroku bill is the Postgres add-on, not the web dyno. Price Heroku Postgres against Render Postgres, Neon, Crunchy Bridge, or RDS/Cloud SQL at your real storage and connection count before you move a single process.
• The cheapest option in raw dollars is Kamal 2 or Dokku on a single Hetzner or DigitalOcean VPS - typically under $50/month for web, workers, Postgres, and Redis together - but you then own backups, Postgres major-version upgrades, TLS renewal, and the 3am page. Budget 2-8 engineer-hours per month and count that as real cost.
• If you want git-push simplicity with the infrastructure in your own cloud account, Qovery runs the Rails web service, the Sidekiq workers, and a managed Postgres inside your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster - so the cloud bill, startup credits, and committed-use discounts stay in your name. It is the right call above roughly 5 engineers, several environments, or a compliance requirement. It is overkill for one app with a 5GB database.
• Before migrating at all: right-size the Postgres plan, auto-sleep or delete idle staging and review apps, and drop unused add-ons. That routinely removes 30-50% of a small Heroku bill with zero migration risk, and a typical Rails migration costs 1-3 focused engineer-days.

Why does a small Rails app on Heroku get expensive so fast?

A small Rails bill climbs because Heroku charges a fixed monthly price per dyno for RAM you rarely fully use, and because the Heroku Postgres add-on jumps in large priced steps driven by connection limits and storage rather than by your traffic. Two Sidekiq workers plus one database upgrade can double the bill in a week without a single extra user showing up.

Here is a realistic small-startup stack at Heroku list prices (checked September 2026):

• Web process on a Standard-2X dyno (1GB RAM): $50/month
• Two Sidekiq worker dynos on Standard-1X (512MB each): $50/month
• Heroku Postgres Standard-0 (4GB RAM, 64GB storage, 200 connections, rollback + point-in-time recovery): $50/month
• Heroku Key-Value Store Premium-0 for Redis (50MB, HA): $15/month
• A staging environment running the same shape 24/7: ~$70/month

That is roughly $235/month before you add Papertrail or an APM, and none of it scales with your traffic. It scales with your process count.

The Postgres step-function is the real problem

The entry Heroku Postgres Essential plans cap connections hard: Essential-0 allows 20 connections, Essential-2 allows 40. That sounds like plenty until you do the Sidekiq math.

Sidekiq defaults to 5 threads per process, and each thread wants its own database connection. So:

• Two worker processes = 2 x 5 = 10 connections before your web app opens a single one.
• A Puma web process at 2 workers x 5 threads = 10 more.
• Add a couple of spare connections per process for reconnects and you are sitting at 25-30 connections while still serving a trickle of traffic.

PostgreSQL ships with max_connections = 100, but the Heroku Essential tier caps you well below that. So you upgrade Postgres for connections long before CPU or storage is the constraint - and the jump from Essential to Standard-0 is the single biggest step on the invoice.

The quiet multipliers

The removal of Heroku's free product plans - announced 25 August 2022, effective 28 November 2022 - is when a lot of small teams started re-pricing their whole stack. The multipliers that hurt most are the ones nobody looks at: a staging app running 168 hours a week, Review Apps left open on merged PRs, per-add-on minimums, and paying a second time for Postgres and Redis in non-production.

To be fair, Heroku still does things most alternatives do not: near-zero ops, the most mature Ruby buildpack in existence, one-command Postgres rollback and follower creation, continuous protection and point-in-time recovery, and a real support path. It is also not frozen - the Fir generation dynos and the move to Cloud Native Buildpacks are recent. You are paying a premium, but you are getting something for it.

What should you compare before moving off Heroku?

Compare five things, not one: runtime price for the web process plus the worker processes, managed Postgres price at your real storage and connection count, how background jobs are modelled, Rails-specific migration effort, and how many engineer-hours per month the platform will cost you. If you only compare the web dyno price, you will pick the wrong platform.

The reference workload I price everything against in this article: a Rails 7/8 app, one web process at ~1GB RAM, two Sidekiq worker processes at ~512MB-1GB each, ~25GB Postgres with daily backups and 7-day retention, Redis for the queues, and one always-available staging environment. Every number below prices that same shape.

The five axes:

• Runtime pricing model. Per-process fixed (Heroku, Render), usage-based per vCPU-hour and GB-RAM-hour (Railway, Fly.io), per-VM (Hetzner, DigitalOcean Droplets), or per-cluster plus per-node (Kubernetes-based platforms including Qovery and Porter).
• Postgres. Managed add-on vs managed cloud database (RDS, Cloud SQL) vs serverless (Neon) vs a self-hosted container. Check what point-in-time recovery, backup retention, storage, and a major-version upgrade actually cost on each.
• Ops load, stated as a number. Who patches the OS, who runs the PostgreSQL major-version upgrade, who renews TLS, who is on call. Put an hours-per-month estimate on every option instead of hand-waving "some maintenance."
• Lock-in and exit. Does the workload run in the vendor's account or yours? Can you take Postgres with you via pg_dump or logical replication? Do AWS Activate, Google for Startups, and Microsoft for Startups credits, and any committed-use discounts, accrue to you or to the vendor?
• Rails specifics. Procfile vs Dockerfile support, DATABASE_URL and RAILS_MASTER_KEY handling, pg_dump/pg_restore vs logical replication, Active Storage bucket migration, a Heroku Scheduler replacement, and the asset precompilation build step.

Which Heroku alternatives are cheapest for a Rails app with Postgres and Sidekiq workers?

The realistic shortlist is Render, Railway, Fly.io, DigitalOcean App Platform, Hatchbox, Kamal 2 on a VPS, and Qovery on your own cloud. They fall into three groups: Heroku-like PaaS (easiest move, vendor's account), automation over your own server (cheapest dollars, you own all the ops), and bring-your-own-cloud (your account, your discounts, a cluster to think about).

Group 1 - Heroku-like PaaS (Render, Railway, Fly.io, DigitalOcean App Platform, Northflank). Your Procfile or Dockerfile maps almost one-to-one. Sidekiq runs as a first-class background worker service with no HTTP port. Postgres is a managed database living in the vendor's account.

• Render. Web on a Standard instance (2GB, $25/month), two Sidekiq workers on Starter ($7 each), Render Postgres with point-in-time recovery included on every paid plan. Closest thing to Heroku's mental model. Render owns your backups.
• Railway. Usage-based: $20/vCPU/month and $10/GB-RAM/month, $20/month Pro workspace with $20 of usage included. Slick UI, Sidekiq runs as its own service, Postgres runs as a database service. The catch: a Sidekiq worker that leaks memory bills you for the leak.
• Fly.io. Machines are cheap ($5.92/month for a 1GB shared-cpu-1x, $3.32 for 512MB). Use Fly Managed Postgres, not the legacy Fly Postgres app - Fly itself warns that the legacy app is unmanaged: "This is not a managed database. If Postgres crashes because it ran out of memory or disk space, you'll need to do a little work to get it back." Fly is the pick when latency across continents matters.
• DigitalOcean App Platform. Instances from $5-25/month, Managed PostgreSQL with daily backups retained 7 days included. Solid, but a thinner Ruby ecosystem than Render.

Group 2 - automation over your own server (Kamal 2, Hatchbox, Dokku, Coolify, Dokploy). A single Hetzner CX box or DigitalOcean Droplet runs web, workers, Postgres, and Redis for tens of dollars a month.

• Kamal 2 ships zero-downtime deploys and automatic Let's Encrypt TLS through kamal-proxy, and runs your web and Sidekiq containers on servers you own. It gives you no managed database at all - Postgres is a container you back up yourself. That is the whole trade.
• Hatchbox is Rails-specific, $15/month per server on top of your VPS, and excellent precisely because it is Rails-aware. It provisions and deploys, but you still own Postgres backups and OS patching.

Group 3 - bring your own cloud (Qovery, Porter, or DIY Kubernetes with Helm and Argo CD). PaaS ergonomics on infrastructure inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster. More on when that is worth it below - for one small app, it usually is not.

Reference workload: Rails 7/8, 1 web (~1GB), 2 Sidekiq workers (~512MB-1GB each), ~25GB Postgres with daily backups + 7-day retention, Redis, 1 staging environment. Capabilities checked September 2026 against each vendor's own docs.

How much can you realistically save, and where does the saving actually come from?

Most of the saving on a small Rails bill comes from two line items - the managed Postgres plan and non-production environments running 24/7 - not from the web dyno everyone stares at. Moving the database is usually worth more than moving the app.

Reference workload as defined above. Every cell is an estimate at list prices checked September 2026; click each linked pricing page and re-check before you budget. Ops hours are converted at $85/hour fully loaded - the US BLS May 2023 mean of $66.40/hour for software developers times a 1.3 overhead multiplier.

The Postgres delta is most of the gap

Look at the Postgres row on its own. Heroku Standard-0 is $50/month for 4GB RAM and rollback. The same ~25GB of data costs about $26 on Render (Basic-1gb plus $0.30/GB storage, PITR included), about $20 on Crunchy Bridge (Hobby-1 plus $0.10/GB storage), about $26 on AWS RDS (db.t4g.small plus 25GB gp3), and storage-only from about $8.75 on Neon before compute. Match the RAM and connections you actually use, not the tier you happen to be on, and this one line often closes the majority of the gap.

The staging saving, with the arithmetic shown

A staging environment does not need to run nights and weekends. There are 168 hours in a week. Staging realistically needs about 40 (weekday business hours). So:

40 / 168 = 0.238 - you pay for about 24% of the compute. On a $120/month staging stack, auto-stopping outside business hours saves roughly $91/month with zero risk. Fly machines auto-stop, and Qovery has environment auto-stop built in for non-production. On Heroku you get most of this by deleting Review Apps the moment their PR merges.

The honest counter-column: engineer-hours

A $200/month saving that costs 8 hours of senior engineering time per month is not a saving. That is why the Hetzner + Kamal 2 column shows ~$25/month of infrastructure but ~$365/month once you price the ops. You now own Postgres backups, the PostgreSQL major-version upgrade, TLS renewal, and the pager.

And watch the costs that only appear on hyperscalers and never on a PaaS invoice: NAT Gateway hourly plus per-GB processing, load balancer hours, snapshot storage, cross-AZ traffic, internet egress beyond the 100GB free tier, and the EKS control-plane fee of $0.10/hour, about $73/month.

The payback rule: (migration engineer-days x loaded day rate) / monthly saving = months to break even. If the answer is over 12 months, stay on Heroku and optimize instead.

What does migrating a Rails app off Heroku actually involve, and how long does it take?

A standard Rails plus Postgres plus Sidekiq app usually moves in one to three days of focused engineering: inventory, containerize, move config vars, restore or replicate the database, cut DNS, and keep Heroku running in parallel until you trust the new stack. The database cutover is the only genuinely risky step.

• Step 1 - inventory. Dynos and sizes, every add-on and its real usage, all config vars, Heroku Scheduler jobs, S3 / Active Storage buckets, custom domains, automated certs, and who holds access.
• Step 2 - build. Use the production Dockerfile that Rails has generated by default since Rails 7.1, or the platform's buildpack. Define separate web and Sidekiq process types rather than cramming both into one container, so you can scale and restart them independently.
• Step 3 - database. pg_dump/pg_restore for datasets under roughly 20-25GB with a short maintenance window (budget about an hour for 25GB, and test the restore first). Use logical replication or a follower plus a final cutover for near-zero downtime. Verify PostgreSQL major-version parity and extensions (pgcrypto, pg_trgm, uuid-ossp, PostGIS).
• Step 4 - cutover. Lower the DNS TTL 24-48 hours ahead, enable maintenance or read-only mode, quiet and drain the Sidekiq queues, flip DATABASE_URL, keep a documented rollback to Heroku, and do not cancel the Heroku plan for at least two weeks.
• Step 5 - replace what you lose. Review Apps become per-PR preview environments, Heroku Scheduler becomes a cron/scheduled job, Papertrail becomes the platform log stream, and Heroku Postgres rollback becomes your new provider's PITR - confirm the retention window matches your old one.

The gotchas worth naming out loud: Sidekiq concurrency x worker count exceeding your Postgres max_connections (recall the 25-30 connections from earlier against a default of 100, or fewer on a small managed plan); needing PgBouncer in transaction mode, which breaks server-side prepared statements unless you configure it; container timezone and locale differences; job idempotency during a dual-write cutover; and forgetting RAILS_MASTER_KEY, which will fail the boot silently at the worst moment.

When is bring-your-own-cloud (and Qovery) the right answer instead of another PaaS?

Bring-your-own-cloud wins when the bill is big enough that committed-use discounts and startup credits matter, or when a customer asks about data residency, VPC peering, or SOC 2. For one app with a 5GB database, one engineer, and no compliance requirements, Render or Fly.io is simpler and usually cheaper, and you should pick those instead.

I will say the disqualifier plainly, because it is what makes the rest of this credible: do not put a toy on a Kubernetes cluster. A cluster has a floor cost - the EKS control-plane fee, nodes, a load balancer, a NAT gateway - and a platform subscription on top. Our own Qovery Business plan lists at $2,999/month billed yearly. For a single small Rails app, that platform fee alone dwarfs the entire Heroku bill you were trying to shrink. Use Render or Fly.io.

BYOC means your apps and databases run inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster. The invoice, the reserved capacity, and any cloud credits stay in your name. What Qovery gives a Rails team, concretely: git-push deployments, a web service plus one or more Sidekiq worker services from the same repository, preview environments per pull request (your Review Apps replacement), environment auto-stop for non-production, managed cluster upgrades, per-environment access control, and Postgres backed by your cloud provider's managed database service.

The crossover usually happens at several services, more than one or two environments, a team around 5-plus engineers, a compliance or residency requirement, or a cloud bill large enough that an AWS Compute Savings Plan (up to 66% off) or a GCP committed-use discount changes the math. At that point the credits matter too: AWS Activate goes up to $200,000, and Microsoft for Startups up to $150,000 - all applied to your own account, worth nothing on someone else's PaaS.

Porter does BYOC well too and belongs on the same shortlist. If you have the platform-engineering headcount, rolling your own Kubernetes with Helm and Argo CD has no license cost - and a real, recurring cost you should price in engineer-days per month. At genuine scale the self-hosting economics get dramatic: 37signals reported their cloud exit will top ten million dollars over five years. That is a big fleet, not a single Rails app - do not read it as advice to buy a rack for your side project.

Which Heroku alternative should you pick for your situation?

Pick by constraint, not by hype: least migration work goes to Render, lowest dollar cost goes to Kamal 2 on a cheap VPS, global latency goes to Fly.io, Rails-specific tooling on your own servers goes to Hatchbox, and a team that wants Heroku ergonomics inside its own cloud account should look at Qovery or Porter.

• "I want to move this weekend and never think about it again." Render - closest Heroku mental model for web plus worker plus managed Postgres. Railway if you prefer usage-based billing and a slicker UI.
• "I am cost-obsessed and have one engineer who genuinely enjoys ops." Kamal 2 on Hetzner or DigitalOcean, or Hatchbox for a Rails-aware UI on servers you own. Accept that you now own Postgres backups and upgrades - Kamal gives you no managed database.
• "My users are spread across continents and latency matters." Fly.io, paired with Fly Managed Postgres or a partner database, never the legacy unmanaged Postgres app.
• "I have compliance, VPC peering, data residency, or committed cloud spend." Qovery or Porter on your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster.
• "My bill is under roughly $150/month and flat." Staying on Heroku is a defensible engineering decision. The migration will cost more in engineer-days than a year of the difference.

Before any migration, run these three optimizations this week: right-size the Postgres plan to actual storage and connection use, delete or auto-sleep idle staging and Review Apps, and cancel the add-ons nobody has opened in three months. That is where the 30-50% lives, and it carries zero migration risk.

What are the cheapest Heroku alternatives for a Rails app with Postgres and Sidekiq worker dynos?

In raw dollars, the cheapest is Kamal 2 or Dokku on a single Hetzner VPS - under $50/month for web, workers, Postgres, and Redis together - as long as you accept owning backups and upgrades. Among managed platforms that keep Heroku-style simplicity, Render, Railway, and Fly.io are all meaningfully cheaper than the equivalent Heroku Standard dynos plus a Heroku Postgres Standard plan.

How much cheaper is Render, Railway, or Fly.io than Heroku for a small Rails app with two worker dynos?

For the reference workload, a stack that costs about $235/month on Heroku lands near $110/month on Render and roughly $190/month on Fly.io at list prices checked September 2026, with Railway close to Render depending on actual usage. Most of the difference is Postgres and the web dyno; the two Sidekiq workers cost about $14 on Render versus $50 on Heroku. Re-check the linked pricing pages, because usage-based platforms vary with your real CPU and RAM.

Can I keep Heroku Review Apps style preview environments after migrating off Heroku?

Yes. Render and Qovery both create a preview environment per pull request out of the box, which is the direct Review Apps replacement. Railway offers PR environments too; Fly.io and DigitalOcean App Platform need you to script it through CI. If per-PR previews are core to your workflow, weight that heavily, because rebuilding them by hand is real work.

How do I migrate a Heroku Postgres database to another provider with minimal downtime?

For a dataset under about 25GB, take a short maintenance window and use pg_dump/pg_restore - budget roughly an hour for 25GB and test the restore before you cut over. For near-zero downtime, use logical replication or a follower and flip DATABASE_URL at the end. Confirm PostgreSQL major-version parity and your extensions (pgcrypto, pg_trgm, uuid-ossp), lower your DNS TTL a day ahead, and keep Heroku running for two weeks as a rollback.

Is it worth moving a small Rails app directly to AWS, GCP, Azure, or Scaleway instead of another PaaS?

Usually not for one small app. A raw cloud account adds a Kubernetes control-plane fee, NAT gateway, and load balancer floor that a PaaS hides, so Render or Fly.io is simpler and cheaper below roughly five engineers. Bring-your-own-cloud through Qovery or Porter becomes worth it once committed-use discounts, startup credits, or a compliance requirement change the math - because then the bill and the discounts stay in your name.

How long does a Rails migration off Heroku take, and what usually breaks?

A standard Rails plus Postgres plus Sidekiq app typically moves in one to three focused engineer-days. What breaks most often: Sidekiq's thread count times your worker count exceeding the new Postgres max_connections, missing RAILS_MASTER_KEY, a Postgres major-version or extension mismatch, and prepared statements failing under PgBouncer transaction pooling. The database cutover is the only genuinely risky step, so keep Heroku live in parallel until you trust the new stack.

Should a small startup just stay on Heroku and optimize the bill instead?

Often, yes. Right-sizing the Postgres plan, deleting idle staging and Review Apps, and dropping unused add-ons routinely cuts 30-50% of a small Heroku bill with zero migration risk. Apply the payback rule: (migration engineer-days x loaded day rate) / monthly saving = months to break even. If that is over 12 months, or your bill is under ~$150/month and flat, staying on Heroku is the rational call.