Migrate from Heroku to Launchverse: Step-by-Step in 2026

Heroku stopped being the default new-project choice years ago, but plenty of established applications still run there. The decision to move is usually triggered by one of three things: pricing changes, a long-tail bug Heroku won't address, or the team wanting more control. Whatever the reason, the migration itself is more straightforward than people fear if you do it in the right order.

This guide walks through a clean Heroku → Launchverse migration end-to-end.

What maps to what

The structural mapping is direct. The work is in the migration choreography — moving your data without losing requests.

1. Inventory your Heroku app

Before you touch Launchverse, snapshot what your Heroku app is doing today:

heroku config -a your-app          # config vars
heroku addons -a your-app          # add-ons (Postgres, Redis, etc.)
heroku ps -a your-app              # dyno count and types
heroku domains -a your-app         # custom domains and SSL setup
heroku scheduler:open -a your-app  # cron jobs

Save those outputs somewhere. You'll re-enter them in Launchverse.

2. Provision the data layer first

Spin up Postgres (and Redis if used) on Launchverse before deploying the application. The data tier should be ready and seeded with a test dataset before any application traffic switches over.

For Postgres specifically:

# 1. Create the Launchverse Postgres database (UI: Resources → Add → PostgreSQL).

# 2. Dump the live Heroku database
heroku pg:backups:capture -a your-app
heroku pg:backups:download -a your-app   # downloads latest.dump

# 3. Restore into the Launchverse database (using credentials from Resources tab)
pg_restore --no-owner --no-acl \
  --host <launchverse-host> --port <launchverse-port> \
  --username <user> --dbname <db> \
  latest.dump

For Redis it's almost always cheaper to start with an empty cache and let it warm up. Cached data on Heroku Redis is rarely worth migrating.

3. Stand up the application on Launchverse

Create a new project, point it at your GitHub repo, and pick the same branch Heroku was building from. The Nixpacks builder will auto-detect Node / Python / Ruby / Go / PHP / Java; for monorepos or unusual stacks, configure the build pack manually or commit a Dockerfile.

If you have a Procfile declaring web: and worker:, treat those as separate Launchverse projects:

Both projects can share the same database via environment variables.

4. Migrate config vars

Copy every Heroku config var into Launchverse environment variables, with two adjustments:

• DATABASE_URL — point to the new Launchverse Postgres connection string, not the Heroku one.
• PORT — Heroku injects PORT for you. Launchverse expects your application to listen on the port it advertises (configured per project; default 3000). Either bind to the configured port or set PORT to match.

Don't carry over Heroku-internal vars (HEROKU_*).

5. Fix the ephemeral filesystem assumption

Heroku is famous for its ephemeral filesystem — files written at runtime disappear on dyno restart. Most teams adapted by writing all uploads to S3 or a CDN. If your app still writes to the local filesystem, this is the moment to fix it. Launchverse containers also restart on each deploy; local files don't survive.

The fix is the same on both platforms: store uploads and generated artefacts in object storage (S3, R2, B2). Launchverse doesn't bundle this, but any provider works — you'll just set credentials in env vars.

6. SSL and custom domains

On Heroku, custom domains required Heroku SSL ($+/month). On Launchverse, every domain gets an automatic Let's Encrypt certificate at no cost. Add the domain in the Domains tab, point your DNS to the new application's IP, and HTTPS provisions in ~30 seconds.

To minimise downtime during the cutover, you can run both old and new apps in parallel:

1. Add the domain on Launchverse (it provisions an SSL cert).
2. Test by hitting the Launchverse application via its *.launchverse.app subdomain.
3. When ready, lower DNS TTL (5 minutes) on your custom domain.
4. Flip the DNS to point at Launchverse.
5. Wait for the TTL to expire (most users hit Launchverse within minutes).
6. Decommission the Heroku app.

7. Migrate the cron jobs

Heroku Scheduler entries need to be reconfigured in Launchverse's project-scoped cron jobs section. Open the project's Overview tab → Cron Jobs → "Schedule job" for each entry:

Commands run inside your application container, identically to heroku run.

8. Common gotchas

• Procfile-based release tasks (release: bin/release). Launchverse runs a "pre-deploy" step in equivalent fashion — set the command in project settings.
• Heroku Connect / specific add-ons. Most are external SaaS that work via API tokens. Set the token as an env var on Launchverse and you're done. Few were Heroku-specific.
• The web process name. Launchverse doesn't care about the process name — it just runs the start command. If your code branches on process.env.DYNO or process.env.PROCESS_NAME, you'll need to rewire it.

Cost comparison (approximate)

For a typical small SaaS — one web app + one worker + Postgres + Redis:

YMMV; both pricing tiers change. The directional answer for small applications is consistently "Launchverse is cheaper" on like-for-like resources.

Further reading

• Deploy a Next.js app on Launchverse without Vercel
• Self-hosted vs managed databases
• Set up a custom domain on Launchverse