Best Heroku alternatives for Docker workloads in 2026

Heroku helped define the PaaS model. Its buildpacks, addons, and dynos made deploying an application unusually easy in 2007, and plenty of production workloads still run there in 2026. But the platform is no longer moving forward. Salesforce put Heroku into sustaining engineering mode in February 2026, limiting the roadmap to security and stability work and Enterprise sales to renewals from existing customers.

Where Heroku hits its limits

The case for moving usually comes down to cost and constraints. A production-oriented baseline with two Standard-1X dynos, a Standard-0 Postgres database, and a Premium-0 Key-Value Store costs $115/month. Lower-cost Basic, Essential, and Mini plans are also available. Sustaining mode also means the platform's current limits are unlikely to change:

• Only HTTP traffic runs on Heroku; no raw TCP or UDP support.
• The filesystem resets on every restart, forcing databases into paid addons.
• Only US and EU regions on standard plans; other regions need Private Spaces.
• Runs only on AWS; no Google Cloud, Azure, or bring-your-own-cloud option.
• Enterprise plans (Private Spaces, private networking) are not sold to new customers.

This guide compares seven alternatives for Docker workloads: Suga, Railway, Render, Northflank, Fly.io, DigitalOcean App Platform, and Google Cloud Run.

Pricing and feature availability were verified on September 15, 2026.

1. Suga

Suga feels familiar if you like Heroku's app model. An environment holds the web tier, workers, and stateful services on one private network.

It covers the features most Heroku users expect:

• Deploy from a Git repository or a container image.
• Auto-detect the runtime; use a Dockerfile for explicit control.
• Long-running services with auto-deploy on push to the tracked branch; pin a version to build without deploying.
• One-click rollbacks.
• Integrated logs and deploy events in the dashboard.
• Custom domains with fully managed TLS.
• Preconfigured database templates (Postgres, Redis, and more) alongside your app.
• Environment variables per service.
• TCP support for non-HTTP workloads on arbitrary ports.

The larger differences show up once an application has several services.

Multi-service environments

Suga groups the web tier, workers, Postgres, Redis, and other stateful services in one environment. Services connect over the private network using internal hostnames. Cross-container variable references let you define a shared value, such as a Postgres password, once and use it wherever it is needed. On Heroku, apps and addons connect through config var strings provisioned by the addon, so a password rotation can require updates to every config var that contains it.

AI-driven config via Suga MCP

Suga exposes an MCP server at `dashboard.suga.app/api/mcp`, so you can set up an environment from an agent conversation instead of working through each dashboard screen. An authenticated agent can create projects, add containers, set environment variables, and connect values across containers. It stages the changes as a draft and gives you the final Apply step. An agent can also drive Heroku's CLI and dashboard commands, such as `heroku config:set` and `heroku ps:scale`, but those commands do not provide the same structured model of the intended platform state.

For example, you could give an MCP-connected agent this prompt:

Add a Qdrant vector store and a MinIO object store to my Suga environment. Wire QDRANT_API_KEY and S3_ACCESS_KEY on the web container so it can reach them.

The agent stages the resulting environment as a draft for you to review:

Environment forking

Environment forking copies the full container graph and its configuration into a separate environment, giving you somewhere to reproduce a production bug without changing production. Heroku pipelines focus on per-PR review apps instead. Recreating production as a named, long-lived staging environment requires you to rebuild it through `app.json` or the Platform API.

Non-sensitive variables copy over by default; for sensitive values (API keys, passwords), you decide per-variable whether to copy or reset in the fork.

Observability

The dashboard shows logs for the entire environment, either grouped or filtered to one container. Deploy events and build history appear alongside them, which makes it easier to match an error spike to a particular deploy.

Additional features

• Persistent volumes per replica, mounted to one machine at a time.
• Custom domains with automatic TLS after you apply the DNS records.
• Bring-your-own-cloud on Enterprise: connect a Kubernetes cluster you provide.
• Cloudflare-fronted automatic HTTPS on Suga-managed hostnames.
• 3 regions, including the United States, Europe, and Australia.

Pricing

• Free tier: $0/month, limited resources.
• Pro: $20/month per seat, including $20 in hosting credits across the organization.
• Enterprise: custom pricing, including bring-your-own-cloud.

A small API (0.25 vCPU, 256 MiB) and database (0.125 vCPU, 512 MiB, 2 GB disk) cost about $17/month, which is covered by the Pro plan's credits. Beyond the included credits, the rates are:

• vCPU: $0.05/hour
• Memory: $0.0054/GB-hour
• Storage: $0.00015/GB-hour
• Egress: $0.12/GB

See Suga's full pricing for volume discounts and Enterprise details.

2. Railway

Railway has a Heroku-like push-to-deploy workflow. Instead of putting everything in one Heroku app, you create several Railway services and connect them within a project.

The familiar parts include:

• Deploy from a GitHub repo or a Docker image.
• Auto-build on push to the tracked branch, with real-time build and deploy logs.
• Long-running services with one-click rollbacks.
• Postgres, Redis, and other database templates provisioned alongside the app.
• Environment variables per service.
• Custom domains with fully managed TLS.

For Docker workloads, two Railway features are particularly useful.

Database services and private networking

Postgres, MySQL, MongoDB, and Redis are deployed from image-backed templates as services in the same project as the application. Private DNS lets services reach one another by name. Environment variables can also reference values from another service (`${{Postgres.DATABASE_URL}}`), keeping shared configuration in one place. Pro volumes default to 50 GB and can be expanded up to 1 TB through self-service controls.

TCP proxy for non-HTTP workloads

Railway's TCP proxy can expose SMTP relays, custom protocols, and WebSocket-heavy workloads on arbitrary ports without wrapping them in HTTP. Heroku does not support this.

Additional features

• Real-time build, deploy, and application logs in the dashboard.
• Per-service CPU, memory, and network metrics.
• Multiple environments per project, including per-PR previews.
• Persistent volumes per service, with snapshots on Pro plans.
• CLI for CI-driven or ad-hoc deploys.
• Multi-region deployment is manual setup per environment, not first-class.
• Workloads run in Railway's own cloud account; no BYOC path today.

Pricing

• Hobby: $5/month, including $5 in usage credits.
• Pro: $20/month per workspace, including $20 in usage credits.

Usage rates beyond credits: ~$0.028/vCPU-hour, ~$0.014/GB memory-hour, $0.05/GB egress. Metered per second.

3. Render

Render treats web services, workers, and cron jobs as separate service types and provides managed data services in the same platform.

Its Heroku-like features include:

• Deploy from GitHub, GitLab, or Bitbucket, or from a Docker image.
• Native runtime detection (Node, Python, Ruby, Go, and more), or a Dockerfile.
• Long-running services with auto-deploy on push and one-click rollbacks.
• Zero-downtime deploys behind automatic health checks for services without persistent disks.
• Managed Postgres and Redis provisioned alongside the app.
• Environment variables per service, or shared through environment groups.
• Custom domains with fully managed TLS.
• Cron jobs, background workers, and web services as native primitives.

Render also has its own model for defining and previewing a complete stack.

Service primitives

Render has distinct types for long-running HTTP services, background workers without an HTTP endpoint, scheduled jobs, private HTTP services, and static sites. That gives the usual Heroku web, worker, and scheduler split a direct Render equivalent.

Blueprint files and PR previews

A `render.yaml` Blueprint keeps the definition for a multi-service stack in the repository. On Pro and higher workspace plans, Render can use that file to create a preview environment for each pull request. Preview datastores start empty rather than copying production data.

Additional features

• Per-service logs, metrics, and health check status in the dashboard.
• Alerts on deploy failures and resource thresholds.
• Persistent disks attached per service; disk-attached services stay at one replica and do not support zero-downtime deploys.
• Workloads run in Render's own infrastructure, with no BYOC path (same as Heroku's cloud-only setup).

Pricing

• Web Services: from $7/month for the smallest always-on tier.
• Managed Postgres: from $6/month.
• Managed Key Value (Redis): from $10/month.
• Static Sites: free.

Usage-based tiers scale up from there based on CPU, memory, and storage. Starter-tier builds run on smaller build resources than paid tiers.

4. Northflank

Northflank is a container platform built on Kubernetes. Its dashboard covers services, databases, jobs, pull-request previews, and resource sizing down to the millicore. That flexibility comes with more concepts to learn than Heroku.

Heroku users will recognize these features:

• Deploy from GitHub, GitLab, or Bitbucket, with buildpack, Dockerfile, or Nixpacks detection.
• Long-running services with auto-deploy on push and one-click rollbacks.
• Managed addons (Postgres, Redis, and more) provisioned alongside the app.
• Environment variables per service, plus shared secret groups.
• Custom domains with fully managed TLS.
• Per-PR preview environments and jobs as native primitives.

Where Northflank stands apart is resource control and preview environments.

Multi-service projects with per-millicore sizing

A project groups web services, background workers, cron jobs, and stateful databases. You can size each service down to the millicore instead of choosing from fixed dyno tiers.

Per-PR preview environments

Each pull request can get a complete environment with its own fresh database, services, and URLs. PostgreSQL, MySQL, and MongoDB addons can optionally be forked from a backup when production-like data is needed. Northflank removes the preview environment when the pull request closes.

Additional features

• Per-service metrics, logs, and events in the dashboard, backed by Kubernetes primitives.
• BYOC into your own AWS, Google Cloud, or Azure account, including on self-service plans.

Pricing

• Smallest compute preset (nf-compute-10): $2.70/month for basic testing.
• Recommended development preset (nf-compute-50): $12/month.

Consumption-based pricing scales linearly: $0.01667/vCPU/hour, $0.00833/GB memory/hour, prorated to the second. Enterprise plans add invoice billing, volume discounts, support, and advanced BYOC options.

5. Fly.io

Fly.io runs Docker images in Firecracker microVMs. Each service gets a machine with a full Linux userspace, block storage, and TCP/UDP support in the regions you choose. This gives you more control over placement, isolation, and network protocols than a conventional PaaS. It also means learning how Fly's Machines, Volumes, Apps, Organizations, and Networks fit together.

Fly still handles several PaaS basics:

• Build and deploy source code or a Docker image with `flyctl`.
• Configure auto-deploys from GitHub with a GitHub Actions workflow.
• Environment variables (Fly calls them secrets).
• Fly Managed Postgres and Upstash Redis alongside your app.
• Custom domains and TLS.
• A CLI driving both local and CI deploys.

The underlying model, however, is closer to lightweight VMs than dynos.

Full Linux VMs with TCP/UDP support

Each Fly Machine is a Linux VM rather than a shared-kernel container. Native TCP and UDP proxying supports MQTT brokers, WebRTC signaling, game servers, and other non-HTTP workloads.

Regional placement across 18 regions

Fly operates in 18 regions and uses a global anycast network. Its proxy sends a request to the nearest running instance. You can change regional placement in `fly.toml` without redesigning the application.

Additional features

• Per-machine logs and metrics via `fly logs` and the dashboard.
• NVMe block storage (Fly Volumes) with per-region residency and snapshotting.
• Fly Postgres, Upstash Redis, and Tigris object storage as add-ons, provisioned as a manual step.
• Machines API for programmatic instance management and inspection.
• OAuth, custom domains, and TLS setup are less automated than on higher-level PaaS.

Pricing

Usage-based, billed per second.

• Shared CPU: from ~$0.0028/hour (shared-cpu-1x).
• Performance CPU: from ~$0.0447/hour (performance-1x).
• Volumes: $0.15/GB per month.
• Egress: $0.02-$0.12/GB depending on region.

Reserved capacity blocks discount compute usage by 40%.

6. DigitalOcean App Platform

DigitalOcean App Platform puts a Heroku-style deployment workflow alongside DigitalOcean's existing compute, database, and networking products.

It provides:

• Deploy from GitHub, GitLab, or Bitbucket.
• Buildpack detection or a Dockerfile.
• Long-running services with auto-deploy on push.
• Web services, workers, jobs, and static sites as native component types.
• Managed Postgres, Redis, MySQL, and MongoDB in the same account.
• Environment variables per component.
• Custom domains with fully managed TLS.
• Deployment previews on pull requests through a GitHub Actions workflow.
• Auto-scaling based on CPU or memory metrics.

The main advantage is how those application services connect to the rest of a DigitalOcean account.

Service primitives

App Platform has component types for HTTP services, background workers, scheduled jobs, and static sites. Each component runs as a separate containerized service on a shared private network.

Managed databases in the same account

Managed Postgres, Redis, MySQL, MongoDB, Spaces, load balancers, VPCs, and DNS management share the same DigitalOcean account. You can connect the relevant resources over private networking.

Additional features

• Alerts on deploy failures, resource thresholds, and downtime, wired into email or Slack.
• Auto-scaling based on CPU or memory metrics.
• Development databases and separate DigitalOcean Managed Databases in the same account; App Platform compute remains stateless.
• Buildpack-first, like Heroku, so less-common runtimes need a Dockerfile.
• Dashboard focuses on single-app config rather than multi-app organization.

Pricing

• Shared CPU containers: from $5/month (1 shared vCPU, 512 MiB RAM); 1 shared vCPU and 2 GiB RAM costs $25/month.
• Dedicated CPU containers: from $29/month (1 dedicated vCPU, 512 MiB RAM).
• Managed Postgres (Development): $7/month.

Flexible container instance pricing lets you customize CPU, memory, and transfer allocations per component.

7. Google Cloud Run

Google Cloud Run runs a Docker image behind an HTTPS endpoint and scales instances with request volume. It makes the most sense for workloads already on Google Cloud or applications that need private access to services such as Cloud SQL, Pub/Sub, and Secret Manager.

Cloud Run handles a narrower set of Heroku's responsibilities:

• Deploy a container image and get an auto-generated HTTPS endpoint.
• Environment variables per service, or injected from Secret Manager.
• Custom domain mapping with Google-managed TLS is available in Preview; Google recommends an external Application Load Balancer for production.
• Logs and metrics via Cloud Logging and Cloud Monitoring.

Cloud Run is a container runtime rather than a complete PaaS. Build pipelines, secrets, and deployment tooling come from other Google Cloud services.

Request-driven autoscaling and traffic splitting

Instances start in response to traffic and scale back down when idle. Each deploy creates a revision, and you can split traffic between revisions for a gradual or canary rollout.

Deep Google Cloud integration

VPC connectors give Cloud Run access to private Google Cloud resources, including Cloud SQL, GKE, and Compute Engine VMs. Secret Manager can inject secrets as environment variables or mounted files, while IAM handles service-to-service and user-to-service authorization. Like Heroku, Cloud Run ties the workload to one cloud provider, although in this case that provider is Google Cloud rather than AWS.

Pricing

Cloud Run offers request-based billing by default and optional instance-based billing. In Tier 1 regions, request-based rates are:

• Requests: $0.40 per million.
• Active vCPU-time: $0.0864/vCPU-hour.
• Active memory: $0.009/GiB-hour.
• Free tier: 2 million requests, 180,000 vCPU-seconds, 360,000 GiB-seconds/month.

Instance-based billing charges for the full instance lifecycle at approximately $0.0648/vCPU-hour and $0.0072/GiB-hour in Tier 1 regions. Minimum instances can also incur idle charges under request-based billing. Rates vary by region.

Additional features

• Cloud Logging and Cloud Monitoring cover logs, metrics, and alerts.
• Cloud Trace and Error Reporting for distributed tracing and stack traces.
• Automatic HTTPS on the generated endpoint; direct custom domain mapping is a Preview feature that Google does not recommend for production.
• Revision-based traffic splitting for canary deploys.
• Containers cap at 8 vCPU / 32 GB per instance, with request timeouts up to 60 minutes.
• Per-PR previews live outside Cloud Run in separate Google Cloud tooling.
• Stateful workloads run on separate Google Cloud services (Cloud SQL, Cloud Storage) since Cloud Run instances are ephemeral.

Migrating from Heroku

A Heroku app usually consists of dynos, addons such as Postgres and Redis, and the config vars that connect them. Migration is easier when the destination has a similar way to group compute and stateful services. In Suga, projects and environments provide that grouping.

Migrating to Suga via MCP

Paste this prompt into an AI agent connected to the Suga MCP.

The agent asks for your redacted Heroku config, creates the project and containers, and connects the environment variables. It then gives you a review link. You add the sensitive values and click Apply when the draft looks right.

Migrating to Suga via Dashboard

Step 1. Create a Suga project and environment.

Log in to the Suga dashboard and create a project and an environment.

Step 2. Add your containers.

Add a container for your web app and a container for your worker. Both point at the same repo, with different start commands taken from your Procfile's `web:` and `worker:` lines.

If the repo doesn't appear in the picker, grant the Suga GitHub App access from its installation page.

Then add Postgres and Redis from the template library. Each template uses a version-tagged image. The Postgres template defines `POSTGRES_USER`, `POSTGRES_DB`, and `POSTGRES_PASSWORD`, with the password marked sensitive, so it can initialize on first boot. The Redis template defines a sensitive `REDIS_PASSWORD`; set its command's `--requirepass` value to `$(REDIS_PASSWORD)` so the deployed container expands the secret.

Both land in the same environment as your web and worker, reachable by internal hostname (`postgres:5432` and `redis:6379`).

Suga auto-detects the runtime and builds; a Dockerfile is only needed for explicit control.

Step 3. Configure environment variables.

Move your non-sensitive Heroku config vars over, then enter secrets directly in Suga. Using cross-container references for shared values, build `DATABASE_URL` as `postgresql://<user>:<password>@<private-hostname>:5432/<database>` and `REDIS_URL` as `redis://:<password>@<private-hostname>:6379`. Use URL-safe passwords, mark both URLs sensitive, and add them to every container that uses them, usually the web and worker containers. If your Postgres container came from a raw image rather than the template library, also set `POSTGRES_USER`, `POSTGRES_DB`, and `POSTGRES_PASSWORD` (the last as a secret) on it so it bootstraps on first boot.

Step 4. Deploy the destination.

Click Apply to create the containers and volumes. Verify the web process at the Suga-generated hostname (`https://<id>.suga.run`) and check the worker's status and logs before moving production data or traffic.

Step 5. Migrate stateful data.

The new Postgres and Redis services start empty. Export and restore your Heroku Postgres data, then verify schema, row counts, and application reads against Suga before cutover. For the final sync, either replicate changes continuously or briefly stop writes on Heroku while you transfer changes made since the first export.

If Redis contains only disposable cache data, you can let it warm from empty. If it stores sessions, queues, or durable application state, migrate or drain that data before switching traffic.

Step 6. Cut over.

After verifying the application and completing the final data sync, point your custom domain at Suga via the custom domains guide to complete the switch.

After the cutover, Suga's logs view shows the web and worker processes together so you can check the migrated application.

Which one to pick

There is no single replacement for every Heroku app. Pick based on what you want to keep from Heroku and what you need to change:

• Suga: close to Heroku's grouping model, with compute, stateful services, and shared configuration in one private environment. Its MCP integration is useful if you want an agent to configure the platform from your codebase.
• Railway: a straightforward push-to-deploy option with database templates in the same project and a TCP proxy for non-HTTP workloads.
• Render: a good fit when you want direct equivalents for Heroku web dynos, workers, and scheduled jobs, plus repository-based stack definitions through Blueprints.
• Northflank: more control over Kubernetes-backed services, including GPU workloads, per-millicore sizing, and complete preview environments for pull requests.
• Fly.io: suited to globally distributed or non-HTTP applications that benefit from 18 regions, TCP/UDP support, and full Linux VMs.
• DigitalOcean App Platform: the natural choice for teams that want a Heroku-style workflow while keeping their databases and networking in DigitalOcean.
• Google Cloud Run: a focused serverless container runtime for applications already using Cloud SQL, VPC connectors, Secret Manager, or other Google Cloud services.

FAQ

Is Heroku shutting down?

No. Salesforce moved Heroku into sustaining engineering mode in February 2026. It will continue to receive security and stability updates, but not new features, and Salesforce is not selling new Enterprise contracts to new customers.

Can I migrate from Heroku without downtime?

Stateless traffic can move without downtime if you keep both platforms running and swap DNS at cutover. Stateful applications also need a database replication or final-sync strategy. Verify the new deployment, stop or synchronize writes to the old database, complete the final data transfer, point the custom domain at the new platform, and decommission Heroku after traffic drains.

Have more questions? Join our Discord.