Heroku built the playbook for developer friendly hosting. Push code, get a URL, scale with a slider. It was genuinely revolutionary. But the Heroku of 2025 is not the Heroku of 2015. Salesforce's acquisition led to years of underinvestment. The free tier disappeared in November 2022. Performance has stagnated while prices stayed high. A basic dyno (512MB RAM, shared CPU) costs $7 per month. A production dyno with 2.5GB RAM costs $250 per month. Heroku Postgres starts at $50 per month for 10 million rows, which is a number many applications hit within their first year.
Meanwhile, a generation of hosting platforms has appeared that match or exceed Heroku's developer experience while offering better performance and lower prices. We have migrated dozens of applications off Heroku as part of our cloud and DevOps work, and the process is more straightforward than most teams expect. This guide covers where to go and how to get there.
Choosing Your Destination
The right platform depends on what you are running. Here is our honest assessment of the options.
Railway is the closest spiritual successor to Heroku. Git push deploys, automatic HTTPS, managed PostgreSQL, Redis, and cron jobs. Pricing is usage based starting at $5 per month for the Pro plan with $5 of included resources. The developer experience is excellent, and the team ships features fast. Best for: small to medium applications, side projects going to production, teams that want Heroku's simplicity with modern pricing.
Render offers a broader platform with web services, background workers, cron jobs, managed PostgreSQL, and Redis. Free tier for static sites and limited web services. Paid plans start at $7 per month for 512MB RAM (same as Heroku's Basic dyno but with dedicated CPU instead of shared). Best for: teams that need a full platform replacement including managed databases and want predictable pricing.
Fly.io deploys Docker containers to edge locations worldwide. Your app runs on bare metal servers in the region closest to your users. More operational control than Railway or Render but also more configuration. Pricing starts at $1.94 per month for the smallest VM. Best for: applications with global users that need low latency, teams comfortable with Docker, and apps that benefit from edge deployment.
Vercel and Netlify are optimized for frontend frameworks (Next.js, Nuxt, SvelteKit) with serverless functions for the backend. If your Heroku app is a monolithic web application that can be restructured into a frontend plus API architecture, Vercel is excellent. If your backend is substantial with background jobs, WebSockets, or long running processes, Vercel is not the right fit for the backend portion. We covered the Vercel vs AWS tradeoffs in detail.
AWS, GCP, or Azure are always an option, but they trade developer experience for flexibility. If your team does not have dedicated DevOps experience, going from Heroku to raw AWS is a step backward in velocity. Use managed platforms for the application layer and cloud providers for specific services (S3 for storage, SES for email) that the hosting platform does not cover. For teams that want the full cloud provider experience, we can help architect the infrastructure as part of our cloud practice.
The Migration Process
Regardless of destination, the migration follows the same phases: database first, then application, then DNS cutover.
Phase 1: Database Migration
Heroku Postgres is the stickiest part. Your options are:
Option A: Managed PostgreSQL on your new platform. Railway, Render, and Fly.io all offer managed Postgres. Export from Heroku using `pg_dump` and import to the new instance using `pg_restore`. For databases under 10GB, this takes minutes. For larger databases, use Heroku's continuous backup or logical replication for zero downtime migration.
```bash
# Export from Heroku
heroku pg:backups:capture --app your-app
heroku pg:backups:download --app your-app
# Restore to new database
pg_restore --no-owner --no-acl -d YOUR_NEW_DATABASE_URL latest.dump
```
Option B: Dedicated managed PostgreSQL. Services like Supabase, Neon, or AWS RDS give you more control over the database independently of where the application runs. Supabase is a strong choice if you want a full backend platform around PostgreSQL with auth, storage, and real time built in. Neon offers serverless Postgres with branching for development workflows. We have a detailed Supabase vs Firebase comparison that covers why PostgreSQL based platforms are worth considering.
Whichever you choose, update your connection strings and test thoroughly. Run your application's test suite against the new database before touching production. Check for PostgreSQL version differences (Heroku often runs older versions). If you are jumping from PostgreSQL 13 to 16, review the release notes for breaking changes. We have a database backup strategy guide that covers what to verify before and after migration.
Phase 2: Application Migration
Heroku applications are typically configured through environment variables and a Procfile. The Procfile declares process types:
```
web: node server.js
worker: node worker.js
release: node migrate.js
```
On Railway and Render, this pattern translates almost directly. Both support Procfiles or equivalent configuration. On Fly.io, you write a `fly.toml` configuration and a Dockerfile (if you do not already have one). On Vercel, the web process becomes serverless functions and the worker needs a separate service.
Key migration steps:
1. Buildpacks to Dockerfiles. Heroku buildpacks automatically detect your language and install dependencies. Modern platforms prefer explicit Dockerfiles or Nixpacks (Railway's open source buildpack alternative). If you do not have a Dockerfile, Railway and Render can auto detect most Node.js, Python, Ruby, and Go applications without one. But creating a Dockerfile gives you reproducible builds and makes you platform independent going forward.
2. Add ons to services. Heroku add ons for Redis, Memcached, Elasticsearch, and other services become standalone managed services. Redis moves to Upstash, Railway Redis, or Render Redis. Elasticsearch moves to Elastic Cloud or OpenSearch on AWS. Map each add on to its replacement and update environment variables accordingly.
3. Environment variables. Export all config vars from Heroku (`heroku config --app your-app`) and import them into your new platform. Double check that no variables reference Heroku specific URLs (like `HEROKU_POSTGRESQL_COLOR_URL`).
4. Background workers. If you run Sidekiq, Celery, BullMQ, or similar job processors, they need their own process on the new platform. Railway and Render support multiple services in a single project. Fly.io handles this with separate apps or process groups.
5. Scheduled jobs. Heroku Scheduler runs simple cron tasks. Replace with the platform's native cron (Railway and Render both have cron job support) or use an external scheduler. For more complex job orchestration, we covered patterns in our CI/CD pipeline guide that apply to scheduled workloads.
Phase 3: DNS Cutover
Once your application is running on the new platform with the migrated database:
1. Lower your DNS TTL to 60 seconds, at least 24 hours before the cutover
2. Put Heroku into maintenance mode
3. Take a final database backup and restore to the new instance (to capture any writes since the initial migration)
4. Update DNS records to point to the new platform
5. Verify everything works
6. Raise DNS TTL back to normal
If your application cannot tolerate any downtime, set up the new instance as a read replica of Heroku Postgres (using logical replication), promote it, and switch DNS with zero data loss. This requires more coordination but keeps your uptime clean.
Cost Comparison
Here is what a typical Heroku application (1 web dyno, 1 worker dyno, PostgreSQL, Redis) costs versus alternatives:
| Component | Heroku | Railway | Render | Fly.io |
|-----------|--------|---------|--------|--------|
| Web server | $25/mo (Standard 1X) | ~$5 to 10/mo | $7/mo | $3.50/mo |
| Worker | $25/mo | ~$5 to 10/mo | $7/mo | $3.50/mo |
| PostgreSQL | $50/mo (Standard 0) | ~$5 to 15/mo | $7/mo | $7/mo (Fly Postgres) |
| Redis | $15/mo (Mini) | ~$5/mo | $10/mo | Via Upstash ~$5/mo |
| Total | $115/mo | ~$20 to 40/mo | ~$31/mo | ~$19/mo |
The savings are significant, often 60 to 80% for equivalent or better performance. A Standard 1X Heroku dyno (512MB, shared CPU) loses to a $7 Render instance (512MB, dedicated CPU) on every benchmark. The cost difference compounds as you scale: running 5 dynos on Heroku costs $125 per month for the web tier alone. The same on Render is $35.
These are the real numbers we show clients when helping them make infrastructure decisions. The comparison page for Veld vs in house engineering covers how we think about infrastructure cost optimization as part of broader engineering strategy.
What to Watch For
Database connection pooling. Heroku's PgBouncer buildpack handled connection pooling automatically. On other platforms, you need to set this up. Supabase includes Supavisor. Neon has built in pooling. For self managed Postgres, run PgBouncer as a sidecar.
SSL certificates. Heroku auto provisions SSL for custom domains. Most alternatives do the same via Let's Encrypt, but verify before cutover.
Log drains and monitoring. If you used Heroku's logging add ons (Papertrail, Logentries), set up equivalent logging on the new platform. Most support log forwarding to Datadog, Betterstack, or similar services. We covered this in our monitoring and observability guide.
Heroku specific features. Review Boards, Pipelines, and GitHub integration have equivalents on most platforms, but the workflow may differ. Railway's PR environments and Render's PR previews replicate the core Review Apps functionality.
If you are ready to move off Heroku and want a team that has done these migrations before, get in touch. We will audit your current setup, recommend the right destination, and execute the migration without disrupting your users or your velocity.