Migrating production infrastructure? Get up to $10K in migration credits.

Apply now
Get started
guides

Leaving Heroku in 2026: A Migration Decision Guide

TL;DR

  • Heroku moved to a sustaining engineering model in February 2026: no new features, and no new Enterprise contracts. The question for most teams is no longer whether to leave but how to move each workload without a risky cutover.
  • Map every Procfile process and add-on to its own target: web dynos to web services, worker dynos to background workers, Scheduler to cron jobs, one-off dynos to one-off jobs, Heroku Postgres and Redis to managed Postgres and Key Value.
  • Plan the database move around a short, rehearsed maintenance window. Heroku doesn't support logical replication with external instances, so pg_dump and pg_restore under a write freeze is the default path.
  • Move stateless compute first, queues second, and data and DNS last, with a written rollback plan.
  • Render maps these workloads one-to-one and defines the whole stack in a render.yaml Blueprint.

Buying cloud infrastructure is straightforward. Migrating a live Heroku production app without breaking it is not.

In February 2026, Heroku announced a sustaining engineering model focused on stability and security, with no new feature development. Existing customers keep their current service, but the roadmap has stopped, and limits like the 30-second request timeout aren't going away. This guide maps your Heroku footprint to its equivalents, sets realistic expectations for the database cutover, and lays out a phased plan for moving each workload.

Should you renew, reduce risk, or move off Heroku in 2026?

Base the decision on capability gaps and measured total cost of ownership, not on general claims about reliability. Look at your own deploy success rate, how often releases were blocked, and how support tickets were resolved over the last year.

Start with workload fit. Heroku's router requires your app to send the first byte of a response within 30 seconds, and the limit isn't configurable. Streaming responses can stay open after that, but only if a byte is sent at least every 55 seconds. AI agents, report generation, and long data pipelines that block on a request don't fit this model, so on Heroku they have to be rebuilt around workers anyway.

Next, compare scaling economics. Heroku's per-dyno pricing climbs quickly as an app grows, and agencies pay for dedicated compute for every client app. Price the same memory and CPU on your shortlisted platforms before you renew.

Finally, check data mobility. Confirm how your Heroku Postgres plan can be exported, how large the database is, and how long a full dump and restore takes. That number sets the length of your maintenance window.

Choosing a Heroku alternative by operating model

This guide is organized around workloads rather than a vendor ranking. The first choice is how much infrastructure your team wants to own:

  • Render: A multi-service cloud platform with the closest one-to-one mapping to Heroku's workload types. Web services, background workers, cron jobs, managed Postgres, and Key Value are all defined in a render.yaml Blueprint.
  • DigitalOcean App Platform: Works well for teams already on DigitalOcean. It runs deploy-time and scheduled jobs. Validate complex database and preview requirements yourself.
  • Fly.io: Fits teams that want control over machine placement across regions. Apps get WireGuard-based private networking by default.
  • AWS or GCP: Scale without limits, but your team owns IAM, networking, orchestration, and cost guardrails.
  • Vercel: Built for frontends and request-driven serverless workloads. Durable background workers usually live on another platform.
  • Northflank: An option when a bring-your-own-cloud (BYOC) mandate requires workloads to run inside your own AWS or GCP account.
  • Railway: Quick to start and popular for early-stage projects. Before committing production workloads, check backup, failover, and compliance requirements against its database documentation.

Agencies running many client apps have different constraints. The Heroku alternatives guide for agencies covers them in detail.

Strategic considerations for multi-tenant billing and BYOC mandates

Agencies and multi-product companies feel Heroku's billing model most, because every client app needs its own dynos and add-ons.

Render's workspace plans are flat rather than per seat. Pro costs $25 per month and Scale costs $499 per month, both with unlimited team members. Bandwidth beyond the included amount is billed at $0.15 per GB, and each custom domain beyond the plan allowance costs $0.25 per month. For an agency, the cost of adding a client grows with that client's compute, not with the size of the team.

Some compliance programs require all data and compute to stay inside the company's own cloud account. If that is a hard requirement, a BYOC platform such as Northflank fits better than any fully managed platform, including Render.

The Heroku migration procurement checklist

Before committing to a provider, have engineering leadership answer these questions for each candidate:

  • Who owns database backups, failover, and version upgrades? Look for managed databases with point-in-time recovery.
  • Are preview environments isolated with their own data? Separate URLs aren't enough if every preview writes to the same staging database.
  • What are the metered costs for egress, cache, and always-on workers? Model a month at your current traffic, not the entry plan.
  • What telemetry exists for failed deploys and queue latency? You'll need it most during the first weeks after cutover.
  • How do you run one-off commands? Migrations, backfills, and consoles need a replacement for heroku run.

Mapping Heroku workloads to Render services

A Procfile is a list of independent processes, not one app. Map each process to the service type that matches how it behaves. A process that binds to a port and accepts inbound traffic is a web service. A process that consumes a queue continuously is a background worker. A process that runs on a schedule is a cron job.

Render defines all of these in a single Blueprint file, render.yaml, so the new topology is version-controlled from the first deploy.

Web dynos to web services

Heroku web dynos map to Render web services, which receive public HTTP traffic on a bound port.

Render's load balancer allows requests to run for up to 100 minutes, which removes the 30-second ceiling for slow endpoints. Longer request timeouts don't make work durable, though: a deploy or restart still kills an in-flight request. Keep long jobs on workers or a workflow engine, and use queues or WebSockets to report progress.

Render builds Node, Ruby, Python, Go, and other runtimes natively, or you can bring a Dockerfile. Python AI apps usually don't need a custom Dockerfile unless they depend on system libraries that the native runtime doesn't include.

Worker dynos and Scheduler to background workers and cron jobs

Heroku worker dynos, such as Sidekiq or Celery consumers, map to Render background workers. They run continuously, receive no public traffic, and scale independently of your web tier.

Heroku Scheduler maps to Render cron jobs. Heroku documents Scheduler execution as expected but not guaranteed, with jobs occasionally skipped or run twice, and limits frequency to every 10 minutes, hourly, or daily. Render cron jobs accept standard cron expressions such as */5 * * * *. Whichever platform you use, make scheduled jobs idempotent so that a duplicate or missed run is harmless.

Release phase and one-off dynos to pre-deploy commands and one-off jobs

The Heroku release process usually runs database migrations. On Render, put that command in the service's pre-deploy command, which runs after the build and before the new version takes traffic. Pre-deploy commands are available on paid services.

Ad hoc heroku run tasks, such as backfills or data fixes, map to Render one-off jobs. A one-off job runs a command against a service's latest build and environment variables, and you can start it from the dashboard or the API.

Heroku Postgres and Redis to Render Postgres and Key Value

Heroku Postgres maps to Render Postgres, a managed database with automated backups. Choose a plan with at least the storage and connection headroom you use today, and match the major Postgres version so that pg_restore doesn't hit version incompatibilities.

Heroku Redis maps to Render Key Value, a managed store compatible with Redis®. New instances run Valkey 8, and paid instances persist data to disk.

Review Apps to preview environments

Heroku Review Apps can provision their own add-ons through app.json, but many teams point them at a shared staging database, and schema changes then collide across branches.

Render preview environments create a copy of every service and database in your Blueprint for each pull request. You turn them on with previews.generation: automatic in render.yaml. The copied databases start empty, so add an initialDeployHook that loads seed data.

AI agents and long-running tasks to background workers and Workflows

AI agents built with frameworks like CrewAI or LangGraph often run for many minutes and fail on platforms with hard request timeouts.

The simplest home for them is a background worker that pulls jobs from a queue. For multi-step jobs that need retries and state between steps, Render Workflows lets you define tasks with Python or TypeScript SDKs. Failed runs retry automatically according to per-task settings. Task runs time out after two hours by default, and you can extend that to 24 hours for each task.

Vercel Workflows is the closest comparison among durable execution engines. A workflow can pause and resume over long periods, but each step is a function invocation, capped at 5 minutes on the Hobby plan and up to 30 minutes on Pro and Enterprise with extended durations, which are in beta. If single steps of your agent run longer than that, a worker or a Render Workflows task avoids splitting them up.

Framework-specific migration paths

The same four steps apply to every framework:

  1. Replace buildpacks with explicit runtimes. Pin language versions in your project files, as your framework expects. If you rely on buildpacks for system packages, move to a Dockerfile.
  2. Convert Procfile entries into build, start, and pre-deploy commands on each service.
  3. Copy config vars. Export them with heroku config --shell and add them to each service, or to a shared environment group when several services use the same values.
  4. Split queue consumers into their own background workers.

Framework guides:

The five-phase Heroku migration plan

Moving everything in one weekend is the most common way these migrations fail. Phase the work instead:

  • Phase 1, inventory: Export config vars, list every add-on, and record each Scheduler job, log drain, and external connection, such as webhooks, IP allowlists, and third-party callbacks.
  • Phase 2, topology as code: Recreate the stack in a render.yaml Blueprint so the new environment is reproducible and reviewed like any other change.
  • Phase 3, stateless compute: Deploy web services and workers against a staging copy of the data. Confirm that builds, health checks, and background jobs behave the same way they did on Heroku.
  • Phase 4, queues: Stand up Key Value and point workers at it. Don't move long-running jobs into web requests just because the timeout is longer.
  • Phase 5, data and DNS cutover: Lower the DNS TTL to 60–300 seconds at least a day before the window. On the day, set a rollback deadline, enable Heroku maintenance mode, and scale Heroku workers to zero. Then dump, restore, and compare row counts on critical tables. Point DNS at Render once the checks pass.

A DNS switch doesn't roll back data. Keep the Heroku app and database intact but read-only until the rollback deadline passes. If validation fails, point DNS back, re-enable the Heroku dynos, and replay any jobs that were enqueued on Render. After the deadline, writes land only on Render, and going back would mean a second migration.

What does "zero downtime" actually mean for a database cutover?

For most Heroku Postgres databases, zero downtime isn't a realistic goal. A short, planned window is.

The constraint comes from Heroku. Its help center states that it doesn't support logical replication from external instances for Heroku Postgres. Without logical replication, you can't keep a database on another provider continuously in sync and then switch over with no write pause.

The standard path is the one Render's Heroku migration guide describes. Put the app in maintenance mode, run pg_dump from Heroku, and run pg_restore into Render Postgres. The guide notes that this step needs downtime, even if brief. How long depends on database size, indexes, and network throughput, so rehearse the full dump and restore against a staging database and use the measured time to set the window. Databases over roughly 20 GB need more care: follow Heroku's guidance for large logical backups, and restore with parallel jobs (pg_restore -j).

Larger or busier databases can do better with help. BeerMenus worked with Render Support to set up a live database sync before cutover and switched over with about 15 minutes of downtime. Contact support early if your database won't restore within a window you can accept.

If you use Heroku Connect to sync with Salesforce, it doesn't move with you. Evaluate a replacement such as DBSync or Stacksync that can write to a standard managed Postgres database, and test it before the cutover date.

Common pitfalls to avoid

  • Assuming zero downtime is automatic: Plan for a write freeze, and measure its length in a rehearsal.
  • Treating cron as a durable workflow: Use cron to trigger work, and let a worker or workflow engine do the long-running part.
  • Lifting and shifting timeouts: A 100-minute request timeout still loses in-flight work on deploy. Long tasks belong in queues.
  • Ignoring preview data isolation: Give every preview its own database and seed script, not just its own URL.

Real-world migration examples

  • ReadMe: After eight years on Heroku, ReadMe moved its Node.js monolith and supporting services to Render. The team placed read-only database followers in the new region before cutover, then promoted one during the maintenance window. The result was about 90 seconds of hard downtime, against a plan that had budgeted hours.
  • BeerMenus: After more than 10 years on Heroku, BeerMenus migrated its Rails, Postgres, and Redis stack to Render. With a live database sync set up alongside Render Support, it cut over with about 15 minutes of downtime at its lowest-traffic hour. Monthly hosting costs fell 35% while capacity went up.

Conclusion

Leaving Heroku is now a sequencing problem more than a platform decision. Teams that map each workload to the right service, move stateless compute before data, and rehearse the database cutover keep downtime to minutes.

If you're planning the move, Render maps Heroku's web, worker, scheduler, Postgres, and Redis workloads to managed services and defines them in a single Blueprint. Sign up for Render and deploy a staging copy of your stack from a render.yaml file.

Sign up for Render

Frequently asked questions