Migrating from Heroku to DeployHQ

Salesforce announced in February 2026 that Heroku is moving to sustaining engineering — security patches, stability fixes, and infrastructure maintenance only. No new features, no new Enterprise contracts, no public roadmap, no sunset date. For most teams this is not an emergency, but it is the right moment to decide whether you want to keep paying for a platform that has stopped evolving.

You have three reasonable answers. This guide covers all of them — including one that is unique to DeployHQ and lets you stay on Heroku entirely.

For related guides if you are weighing self-hosted PaaS options that share Heroku's shape, see Migrating from Dokku to DeployHQ and Migrating from Coolify to DeployHQ. If your Heroku deploys currently run from a CI pipeline, Migrating from GitHub Actions to DeployHQ covers the hybrid pattern.

Three migration paths

Path 1: Stay on Heroku, add DeployHQ as the deploy and governance layer

This is the path no other migration guide in this series can offer. DeployHQ has a native Heroku server protocol — you keep your Heroku app, your dynos, your add-ons, your git push heroku main workflow if you want it, and DeployHQ becomes the orchestration layer in front. You get:

• Audit log of every deploy — who, what, when, which commit, which branch
• Per-environment deploy permissions — staging access without production access
• Build pipelines that run once on our infrastructure and ship the result to Heroku, instead of Heroku rebuilding from scratch on every push
• Web UI, CLI, REST and GraphQL API, automatic deployments
• AI deploy error explanation — failed deploys summarised in plain English with a likely fix

Concretely: add a server in your DeployHQ project, pick Heroku as the protocol, paste your Heroku API key, select your app from the list. Done. Your Heroku setup is unchanged; you now have everything the Heroku dashboard does not give you.

This is the cheapest move. Zero infrastructure changes. If sustaining engineering does not bother you long-term, this might be the only step you ever need to take.

Path 2: Lift-and-shift to your own VPS with file-based atomic releases

If the long-term direction is "off Heroku entirely" — usually because of cost at scale, vendor risk, or wanting your apps next to your data — DeployHQ runs the deploy half of that move. The infrastructure half is yours to provision, or use the Managed VPS beta to do it inside the same dashboard.

Be honest about what changes:

What Heroku gives you	What you take on
Container-based deploys via buildpacks	Different model. Atomic file-based releases via symlinked release directories. Buildpack work moves into build pipelines.
git push heroku main to deploy	Push to your normal Git remote — DeployHQ deploys via automatic deployments on every push to a tracked branch.
Heroku router with automatic SSL	You manage this. Caddy (recommended for new setups — automatic Let's Encrypt out of the box), nginx + certbot, or a managed load balancer in front.
heroku addons:create heroku-postgresql	External services. Managed Postgres (RDS, Neon, Supabase, your VPS provider's managed offering), or self-host on a dedicated server.
heroku config:set KEY=value	Environment variables per project, global env vars for values shared across projects.
heroku ps:scale web=3 worker=2	Process management is your concern — systemd, supervisord, or a Procfile-runner of choice. DeployHQ deploys the code; you decide how it runs.
heroku logs --tail, heroku run rails console	SSH directly into the server, plus your log aggregator of choice (Better Stack, Papertrail, Logtail).
Review apps and pipelines	Separate DeployHQ projects per environment, plus webhook-driven PR deploys via the API.

Read that table before committing to this path. Heroku does a lot for you. Replacing it means owning more of the operations.

Path 3: Hybrid — keep critical apps on Heroku, move the rest

Most teams with one big Heroku app and several smaller side projects find that the side projects (the marketing site, the internal tool, the cron worker) are the ones causing the most friction with Heroku's per-dyno pricing. Move those to a VPS via DeployHQ, keep the main app on Heroku — managed via Path 1 or directly — and reassess in a year.

There is no requirement to move everything.

Feature parity: Heroku to DeployHQ (Path 2)

Heroku	DeployHQ
Heroku app and pipelines	DeployHQ project per app, environment per stage
git push heroku main	Push to your Git remote — DeployHQ deploys on the webhook
Buildpack autodetection (bundle install, npm ci, composer install, asset compilation)	Build pipeline steps — explicit, version-controlled, built once and shipped to N servers
Procfile (web:, worker:, release:)	systemd units (or supervisord) for web and worker. The release: phase becomes an SSH command set to run after upload, before symlink change
heroku config:set	Environment variables; global env vars for shared values
heroku addons:create	Managed services from your cloud provider, or self-hosted on a separate server
Numbered slugs and heroku rollback v123	One-click rollback to any prior deploy via symlink swap
Heroku activity feed	Audit log of every deploy with commit hash, branch, deployer, and timestamp
Heroku CLI	DeployHQ CLI — deployhq deploy production
Review apps	Separate DeployHQ projects per branch, plus webhook-driven PR deploys
heroku ps:exec	Direct SSH into your server

What DeployHQ adds that Heroku never did

Capability	Why it matters
Bring your own server	Any SSH-reachable host — bare metal, VPS, EC2, your existing on-prem box. Heroku locked you into Heroku-managed dynos.
Multiple deploy targets per project	The same DeployHQ project can deploy to AWS Elastic Beanstalk, Heroku, FTP, SSH, and more.
Build pipelines off the target	Heroku rebuilt your slug from scratch on every push. DeployHQ builds once on our infrastructure and ships the artifact to N servers in parallel.
Per-environment deploy permissions	Grant deploy-to-staging without granting deploy-to-production. Heroku's collaborator model is per-app, not per-stage.
AI deploy error explanation	When a deploy fails, the failed step is summarised in plain English with a likely fix.
Managed VPS beta	If you do not have a server yet, provision one inside DeployHQ with SSH keys handled automatically.

Migration in three steps (Path 2)

1. Stand up the new server

Provision a server (Hetzner, DigitalOcean, Linode, AWS, your own bare metal — anything SSH-reachable). Install your runtime directly: PHP-FPM, Puma, Gunicorn, PM2 — whatever the buildpack was doing inside the dyno. Install Caddy for SSL and routing — a single caddy.example.com { reverse_proxy localhost:3000 } block plus automatic Let's Encrypt is the closest one-step replacement for Heroku's router.

If you would rather have this off your plate, the Managed VPS beta provisions a server inside DeployHQ in a couple of clicks.

2. Replicate the buildpack as a build pipeline

Heroku buildpacks resolve to a small set of commands. Translate them into build pipeline steps:

• Ruby/Rails: bundle install --deployment --without development test, bundle exec rails assets:precompile
• Node: npm ci --omit=dev, npm run build
• PHP/Laravel: composer install --no-dev --optimize-autoloader, npm ci && npm run build
• Python/Django: pip install -r requirements.txt, python manage.py collectstatic --noinput

These run once on our build infrastructure; the resulting release ships to every target server. On Heroku, every dyno rebuilt this on every restart — you are reclaiming that time.

3. Translate the Procfile into systemd units and SSH commands

Each line of your Procfile becomes either a systemd unit (long-running process) or an SSH command (one-shot per deploy):

• web: bundle exec puma becomes a systemd unit, restarted by an SSH command (sudo systemctl reload puma) tied to after deploy
• worker: bundle exec sidekiq becomes a systemd unit, restarted by an SSH command tied to after deploy
• release: bundle exec rails db:migrate becomes an SSH command set to run after upload, before symlink change — the same semantics as Heroku's release phase

For most Heroku apps without exotic add-ons, end-to-end migration is a full day per app, plus a parallel-running window before you scale dynos to zero. Concierge migration is available on Pro and above — point us at your Heroku app and we will do the migration with you on a screenshare.

What teams ask before they switch

Is sustaining engineering the same as end-of-life? No. Salesforce will keep the lights on — security patches, stability fixes, infrastructure maintenance. There is no sunset date. The platform has simply stopped getting new features and is no longer accepting new Enterprise customers. If your app is small and stable, you can stay on Heroku indefinitely. The question is whether you want to keep paying for a platform that has stopped evolving.

Do I have to move my database at the same time? No. Heroku Postgres is reachable from anywhere over the public internet. Many teams cut over the app first (Path 2), keep Heroku Postgres for a few weeks, then migrate the database at their own pace using pg_dump and pg_restore into a managed Postgres of their choice.

Can I keep using Heroku for production and DeployHQ-managed VPS for staging? Yes — that is Path 3, in shape. Two DeployHQ projects: production points at a Heroku server (Path 1 protocol), staging points at your VPS. Same code, same Git workflow, two targets.

What about Heroku's review apps? DeployHQ does not have a one-click review-app equivalent, but per-branch automatic deployments to ephemeral environments cover the same ground with a small amount of setup. Many teams use one DeployHQ project per long-lived branch, or wire PR webhooks to spin up environments via the API.

Do I lose heroku run rails console? No — you SSH directly into your server and run it there. The Heroku CLI was a wrapper around SSH-into-an-isolated-container; the equivalent on a normal server is ssh deploy@example.com then cd /var/www/app/current && bin/rails console.

What about logs? heroku logs --tail becomes whatever log aggregator you configure — Better Stack (we have a Better Stack integration guide), Papertrail, Logtail, or journalctl -u puma -f directly on the server.

Can I deploy to Heroku from DeployHQ today, before I commit to leaving? Yes — see Configuring a Heroku Server. This is Path 1: keep Heroku, gain the DeployHQ governance layer. Zero infrastructure changes, ten minutes of setup.

Start your migration

If you want the smallest possible move, take Path 1: add a Heroku server in your DeployHQ project and you have an audit log, RBAC, build pipelines, and AI error explanation in front of your existing Heroku setup within ten minutes. No infrastructure changes.

If sustaining engineering is the cue to leave entirely, take Path 2: stand up a server (or use the Managed VPS beta), replicate your buildpack as a build pipeline, translate your Procfile into systemd units and SSH commands, and migrate one app at a time. Plan a full day per app and a parallel-running period before you scale Heroku dynos to zero.

If your stack is part Heroku-shaped and part not, Path 3 (hybrid) is the honest answer — there is no requirement to move everything.

Heroku is a trademark of Salesforce, Inc. DeployHQ is not affiliated with Heroku or Salesforce. We just understand what it looks like when a platform you have relied on for a decade quietly stops adding features.