Deploying Hatchbox: your own Heroku on any VPS.: what should I watch out for? (#1)

Hatchbox provisions Nginx and Puma directly on the VM — not containers. If your team wants Docker, use Hatchbox for the control plane but deploy via its Docker mode.

Deploying Hatchbox: your own Heroku on any VPS.: what should I watch out for? (#2)

The app-server Postgres is fine for staging or hobby apps. For prod, plan the migration to a managed DB early — snapshots on the same box are not a backup strategy.

Deploying Hatchbox: your own Heroku on any VPS.: what should I watch out for? (#3)

Zero-downtime deploys require at least 2 web processes (Puma workers). On a 1 GB VM this can be tight; upgrade to 2 GB or use a swapfile before enabling.

Deploying Hatchbox: your own Heroku on any VPS.: what should I watch out for? (#4)

Hatchbox needs SSH access to the VM. Lock the box down to Hatchbox's IPs and your team's, and disable password auth.

// cloud · hatchbox

Hatchbox: your own Heroku on any VPS.

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

Hatchbox.io is the sweet spot between "git push heroku" and "run your own Kubernetes." You point it at a DigitalOcean, Hetzner, Linode, Vultr or AWS box, connect your repo, and it provisions Nginx, Puma, Postgres, Redis, Sidekiq, Let's Encrypt and zero-downtime deploys for you. Rails-first, but any Rack app works.

~8 min

provision → first deploy

Nginx · Puma · PG · Redis · Sidekiq

managed pieces

DO · Hetzner · Linode · Vultr · AWS

supported providers

01 / 05

Bring your own box

Hatchbox doesn't sell compute — it manages compute you already run. Pick any modest x86_64 Linux VM (Hetzner CX-series, DigitalOcean droplets, EC2 t-class), give it a public IP and SSH, and Hatchbox does the rest. Promote to a managed Postgres once traffic outgrows the app-server DB.

02 / 05

Connect the repo, deploy

Point Hatchbox at your GitHub repo, pick a branch, add ENV vars. The first deploy provisions Ruby (via rbenv), Node/Bun for assets, Nginx, Puma, and TLS via Let's Encrypt. Every subsequent push is a rolling restart.

yml
# .hatchbox.yml (optional — Hatchbox autodetects most Rails apps)
services:
  web:
    processes: 2
    memory_limit: 512
  worker:
    command: bundle exec sidekiq -c 5
env:
  RAILS_LOG_TO_STDOUT: "true"
  RAILS_SERVE_STATIC_FILES: "true"

03 / 05

Databases: managed or on-box

Start with the Postgres Hatchbox installs on your app server. When traffic or the backup story gets serious, add a managed DB (DigitalOcean, Hetzner, or Amazon RDS) and swap the DATABASE_URL — no other changes.

04 / 05

Background jobs

Hatchbox has first-class Sidekiq support (with a UI to view queues) and works fine with Solid Queue. Point a dedicated 'worker' process at your queue command and it gets the same rolling-deploy treatment as web.

05 / 05

Rollbacks and console

One-click rollback to the previous release, plus a browser-based Rails console straight from the dashboard. It's the Heroku experience — on your own hardware.

Gotchas we learned the hard way

!Hatchbox provisions Nginx and Puma directly on the VM — not containers. If your team wants Docker, use Hatchbox for the control plane but deploy via its Docker mode.
!The app-server Postgres is fine for staging or hobby apps. For prod, plan the migration to a managed DB early — snapshots on the same box are not a backup strategy.
!Zero-downtime deploys require at least 2 web processes (Puma workers). On a 1 GB VM this can be tight; upgrade to 2 GB or use a swapfile before enabling.
!Hatchbox needs SSH access to the VM. Lock the box down to Hatchbox's IPs and your team's, and disable password auth.