Deploying Heroku: still the fastest path to prod.: what should I watch out for? (#1)

Dynos restart every 24h. Any in-memory state is lost. This is a feature — treat it like one.

Deploying Heroku: still the fastest path to prod.: what should I watch out for? (#2)

Heroku Postgres connections are precious. Use pgbouncer (a buildpack) or PgBouncer via Heroku Data if you have more than one dyno.

Deploying Heroku: still the fastest path to prod.: what should I watch out for? (#3)

Slug size limit is 500 MB uncompressed. Node modules and Puppeteer will eat that fast — containerize before you hit the wall.

Deploying Heroku: still the fastest path to prod.: what should I watch out for? (#4)

Run staging on the same stack as prod (same Postgres tier, same dyno type). A slimmed-down staging that behaves differently is worse than no staging.

// cloud · heroku

Heroku: still the fastest path to prod.

Where Rails grew up. Still the fastest zero-to-production experience for a solo founder or small team, in 2026.

Heroku's superpower is operational simplicity. It gives you a running, monitored, backed-up, TLS-terminated Rails app on the internet in minutes — with rolling deploys, review apps and managed Postgres wired in.

~90 s

time from git push to prod

~2 min

review app boot

Standard-1X

smallest sane prod dyno

01 / 04

Buildpack or container — pick one

The Ruby buildpack is the classic 'git push heroku main' experience — no Dockerfile needed. For anything non-trivial, use container deploys (`heroku container:push web`) and you get the same image on Heroku, staging, and local.

bash
heroku container:login
heroku container:push web --app my-rails-app
heroku container:release web --app my-rails-app
heroku run rails db:migrate --app my-rails-app

02 / 04

Postgres tiers matter

For any real traffic, pick a Standard-tier Postgres — the connection limits (120+) match what a small Rails app with a handful of dynos actually needs. Enable follower dbs before you need them; promoting is one command.

03 / 04

Pipelines & review apps

Pipelines give you dev → staging → prod with promote-by-slug (no rebuild) — the same artifact runs everywhere, which kills a whole category of 'works on my staging' bugs. Review apps spin up a full stack per PR.

04 / 04

Solid Queue instead of Heroku Scheduler

For anything more than one cron job per hour, run Solid Queue on a worker dyno and use `recurring.yml`. Heroku Scheduler is fine for the one nightly report you'll write.

Gotchas we learned the hard way

!Dynos restart every 24h. Any in-memory state is lost. This is a feature — treat it like one.
!Heroku Postgres connections are precious. Use pgbouncer (a buildpack) or PgBouncer via Heroku Data if you have more than one dyno.
!Slug size limit is 500 MB uncompressed. Node modules and Puppeteer will eat that fast — containerize before you hit the wall.
!Run staging on the same stack as prod (same Postgres tier, same dyno type). A slimmed-down staging that behaves differently is worse than no staging.

Related guides

→ guide

Framework · Rails

The majestic monolith is back, and it deploys better than ever. Kamal 2, Solid stack, Propshaft — no Node, no Redis, no Nginx if you don't want them.

→ guide

Framework · Sinatra

The 40-line Dockerfile framework. Perfect for internal APIs, webhooks, and 'we just need one endpoint' services.

→ guide

Framework · Padrino

Admin panels, mailers, and mountable subapps — deployed with the same care as any modern Ruby stack.

→ guide

Cloud · Hatchbox

By Chris Oliver of GoRails. A managed control plane over VMs you own — Heroku ergonomics on infrastructure you control end to end.

→ guide

Cloud · GCP

Cloud Run is what happens when you take Heroku and give it an actually good autoscaler. It's the sweet spot for most Ruby teams.

Ready?

Push to Heroku in the next 10 minutes

Nothing beats it for velocity in the first year. When you outgrow the platform's ceilings, migrate — we've got best-practice guides for AWS, Azure and GCP.