How do I migrate from Heroku to something cheaper?

Migrating off Heroku can be pretty straightforward if you do it in a controlled way. The cheapest move depends on what you’re running, but the process is usually:

1) Figure out what Heroku is doing for you

List every Heroku feature you use:

• Web app dynos
• Worker dynos / background jobs
• Postgres / Redis add-ons
• Scheduled jobs
• File storage
• Environment variables
• Domains / SSL
• Review apps / pipelines
• Logs / monitoring

This matters because Heroku often bundles all the “ops” work into one place, and the replacement may be split across a few services.

2) Pick a cheaper target

Common lower-cost options:

Easiest “still managed” options

• Render – similar developer experience, often cheaper for small apps
• Railway – simple deploys, good for prototypes/small apps
• Fly.io – flexible, can be cheap for small/low-traffic apps
• DigitalOcean App Platform – simpler managed platform, moderate cost

Cheapest if you’re okay with more setup

• A VPS from:
  • DigitalOcean
  • Hetzner
  • Linode/Akamai
  • Vultr
• Run your app with:
  • Docker
  • systemd
  • Nginx/Caddy
  • PostgreSQL/Redis either self-managed or separate managed services

If your app is mostly static or serverless-friendly

• Cloudflare Pages + Workers
• Vercel
• Netlify

3) Check compatibility

Before moving, verify:

• Does your app depend on Heroku-specific buildpacks?
• Does it assume an ephemeral filesystem?
• Is it using Heroku scheduler or queues?
• Does it need a managed Postgres/Redis equivalent?
• Are you using dyno sleeping behavior, routing, or release-phase hooks?

4) Dockerize if possible

Even if you don’t use Docker in production, it makes migration easier.

A typical path:

• Add a Dockerfile
• Ensure the app listens on PORT
• Read config from environment variables
• Store uploads in S3-compatible storage instead of local disk
• Make startup idempotent

If you’re on Node, Python, Ruby, Go, etc., this usually isn’t too hard.

5) Move your data first

If you use Heroku Postgres:

• Create a new database on your target platform
• Run a dump/restore:
  • pg_dump from Heroku
  • psql restore to new DB
• Test the app against the new DB before switching traffic

If you use Redis:

• Check whether it’s cache-only or persistent
• If cache-only, you may be able to just recreate it
• If it stores important data, plan a migration carefully

If you store files on local disk:

• Move them to S3, Cloudflare R2, Backblaze B2, etc.

6) Deploy the app to the new platform

Typical order:

1. Set env vars/secrets
2. Build and deploy app
3. Run migrations
4. Test on a staging URL
5. Verify background jobs and cron tasks
6. Confirm logs, metrics, and error handling

7) Cut over traffic gradually

• Lower DNS TTL ahead of time
• Point domain to the new platform
• Keep Heroku running for a short rollback window
• Watch for errors, timeouts, missing env vars, database issues

8) Shut down Heroku services

Once stable:

• Remove dynos you no longer need
• Delete unused add-ons
• Export logs/config if needed
• Then fully shut down the app to stop billing

---

A practical “cheapest” migration path

If you want low cost with low pain, a common setup is:

• App: Render / Fly.io / VPS
• Database: Managed Postgres elsewhere or self-hosted on a VPS
• Cache/queue: Redis on a small VPS or managed Redis
• Files: S3/R2/B2
• Cron: system cron, Render cron, GitHub Actions, or platform scheduler

---

Rule of thumb

• Small app, want easy → Render / Fly.io / Railway
• Want absolute lowest monthly cost → small VPS + Docker + managed DB/storage
• Static/frontend only → Cloudflare Pages/Vercel/Netlify

If you want, I can help you with a migration plan tailored to your stack. Tell me:

1. what language/framework you use,
2. whether you use Postgres/Redis/background jobs,
3. and your rough monthly Heroku bill.