How to migrate from Heroku to DeployCloud

Good news: most of it carries over

If your app runs on Heroku today, you already follow the conventions DeployCloud expects. The Procfile, config vars and DATABASE_URL all map across almost one-to-one. The migration is mostly re-pointing, not rewriting.

• Procfile — your existing web: (and any worker:/release:) processes work as-is.
• Config vars — become environment variables on the new platform.
• Heroku Postgres — becomes a managed Postgres add-on; you migrate the data with pg_dump/pg_restore.
• Buildpacks — replaced by Nixpacks auto-detection (same languages) or your own Dockerfile.
• Git push to deploy — the workflow is identical: push a branch, it builds and releases.

Step 1 — Create your app on DeployCloud

There is nothing to provision, install or patch — DeployCloud builds and runs your app on our infrastructure. Connect your Git repo and create an app; every app gets its own subdomain with automatic HTTPS out of the box, exactly like *.herokuapp.com. The Free plan needs no credit card, so you can stand up a working copy before you commit.

Step 2 — Bring your Procfile as-is

Your Procfile is the contract. A typical one already declares everything the new platform needs:

web: node server.js
worker: node worker.js
release: npx prisma migrate deploy

The release process runs before traffic shifts — the same guarantee Heroku's release phase gives you, so migrations run exactly once per deploy.

Step 3 — Move config vars to env vars

Export your Heroku config and set the same keys on the new app. On Heroku:

heroku config -s -a your-app > heroku.env

Then set each key on DeployCloud (via the dashboard, the API or the CLI). They are encrypted at rest, and you can scope them per environment (production vs preview).

Step 4 — Migrate the database

Provision a managed Postgres add-on on DeployCloud, then copy the data across with a standard dump and restore:

# from Heroku
pg_dump $(heroku config:get DATABASE_URL -a your-app) -Fc -f db.dump

# into the new managed Postgres
pg_restore --no-owner -d "$NEW_DATABASE_URL" db.dump

Step 5 — Replace buildpacks

Heroku buildpacks map to Nixpacks, which auto-detects Node, Python, Go, Ruby, PHP, Rust, Java and more — no configuration for a standard app. If you need full control, drop a Dockerfile in the repo and it builds that instead. Either way the output is the same: a container that runs your Procfile processes.

Step 6 — Deploy, verify, then cut over DNS

1. 1Connect the repo and push a branch — DeployCloud builds and releases it to a subdomain.
2. 2Run a one-off command if you need to seed or check something (the equivalent of heroku run).
3. 3Smoke-test the app on its new subdomain with the migrated database.
4. 4Add your custom domain and point your real domain's DNS at DeployCloud, then confirm HTTPS is issued automatically.
5. 5Keep the Heroku app around, scaled to zero, until you are confident — then decommission it.

What you gain

You keep the git-push workflow you already know and drop the parts of Heroku that add up. Pricing is flat and predictable — $19/mo Pro or $99/mo Business, not per-dyno, per-seat or metered add-ons, with no surprise egress. And it is one complete platform: preview environments with GitHub PR feedback, managed Postgres/Redis/S3 add-ons, time-series metrics and threshold alerts, scheduled backups with one-click restore, cron jobs, health-checked zero-downtime deploys and one-click rollback are all included — fully managed, with zero ops for you to run. Especially since Heroku retired its free tier, that trade is worth it for many teams.