An opinionated list of platforms teams reach for when they outgrow Heroku. Covers managed PaaS, edge platforms, Kubernetes-simplified options, and self-hosted OSS.

Long-form reasoning behind each pick lives in the full write-up: 9 Heroku Alternatives Worth Trying in 2026.

• Runtime model — always-on containers vs short-lived function invocations
• Pricing structure — flat workspace + per-second compute vs pure usage-based
• Regional coverage — how close your app runs to your users and existing databases
• Edge tier — whether CDN, WAF, and DDoS come by default or as separate vendors
• Whose infrastructure — vendor-managed only, or bring-your-own-cloud / cluster

Legend: ✅ built-in · 🟡 partial or paid add-on · ❌ not offered

suga.app — visual canvas plus push-to-deploy, with an edge tier included and infrastructure-as-code discipline (audit trail, environment forking, one-click rollback). Workloads run as containers on managed infrastructure fronted by Cloudflare.

• Best for: teams that want fast deploys with an audit trail, environment forking for testing, and edge protection by default. Enterprises with existing cloud commitments wanting a BYOC control plane.
• Consider elsewhere if: you need very large per-instance memory ceilings today, published SOC 2 / ISO 27001, or a mature first-party managed Postgres with point-in-time recovery.
• Pricing: Free tier for evaluation · Pro is per-seat with $20 of hosting credits included per seat · Enterprise custom with BYOC.

render.com — closest one-to-one Heroku replacement. Push a repo, Render detects the runtime or reads a Dockerfile, service comes up on managed infrastructure with automatic TLS, health checks, and zero-downtime deploys.

• Best for: teams who want Heroku's DX with wider instance sizes (up to 32 GB / 8 CPU), first-party managed Postgres with point-in-time recovery, and published compliance (SOC 2, ISO 27001, HIPAA on Scale).
• Consider elsewhere if: you need to run on your own infrastructure, or your traffic is spiky enough that flat workspace fees plus per-second compute metering doesn't fit as cleanly as pure usage-based billing.
• Pricing: Free hobby tier with sleep · Pro from $25 per month workspace fee plus compute metered by the second · Scale plan for larger teams.

railway.com — canvas-first application composition. Drop services on a canvas, wire databases, workers, and crons together, and Railway handles networking and secrets between them.

• Best for: small teams and startups wanting a single project canvas showing everything running, plus straightforward per-minute billing on CPU and RAM. SSH into running containers is distinctive.
• Consider elsewhere if: you need L7 DDoS protection and WAF at the edge without adding a separate provider, or you need to run on your own infrastructure.
• Pricing: Hobby from $5 per month with compute metered per minute · Team plans add collaboration and higher limits.

fly.io — micro-VMs distributed across dozens of regions worldwide. "Run this container close to the user" is baked into how you design the deployment from the start.

• Best for: latency-sensitive apps, multi-region topologies, and workloads that benefit from geographic distribution as a first-class primitive.
• Consider elsewhere if: you have a single-region app backed by a single-region database. Much of Fly's distinctive value comes from the multi-region model.
• Pricing: Usage-based across CPU, RAM, and bandwidth · Small always-on hobby footprint free.

vercel.com — serverless-functions runtime tuned for Next.js frontends and thin API layers. Edge-cached static assets, preview environments on every pull request.

• Best for: Next.js frontends, marketing sites, JAMstack applications, and teams whose "backend" is mostly a thin API in front of managed services.
• Consider elsewhere if: your workload is a long-running process, holds open WebSocket connections, runs background workers, or does heavy in-process caching that scale-to-zero would evict.
• Pricing: Hobby free with usage limits · Pro from $20 per user per month plus usage-based function invocations and bandwidth.

porter.run — Heroku DX on top of Kubernetes. Push-to-deploy flow, sensible defaults for TLS and autoscaling, ability to graduate into raw Kubernetes primitives when needed.

• Best for: teams who expect to end up on Kubernetes eventually and want a gradient into it, or teams who already have cluster infrastructure they want to keep using with a nicer deploy loop on top.
• Consider elsewhere if: you have no interest in Kubernetes concepts leaking into your day-to-day work, or you want a fully managed platform with no cluster-level decisions to make.
• Pricing: Metered by compute usage on Porter Cloud · Self-hosted options for teams running on their own AWS, GCP, or Azure accounts.

dokploy.com — self-hosted PaaS on top of Docker and Docker Swarm. Application dashboard, database provisioning, and deploy flows on infrastructure you rent yourself.

• Best for: developers comfortable managing a VPS, wanting maximum control over the underlying host, with workloads whose economics benefit from a fixed monthly VM bill rather than usage-based metering.
• Consider elsewhere if: you'd rather not manage host-level concerns (OS updates, backups, VPS-level networking), or you want a platform team's support contract behind your production infrastructure.
• Pricing: Open source and free to self-host · Paid cloud option for teams that want the same platform without running the host.

coolify.io — self-hosted PaaS with a substantial community. Connect a Git repo or Docker image, provision databases as containers on the same host, automatic TLS via Let's Encrypt.

• Best for: solo developers and small teams wanting a self-hosted PaaS with an active community, first-class support for a wide range of databases as containers, and no per-service pricing.
• Consider elsewhere if: the workload really needs multi-region deployment, managed Postgres with point-in-time recovery, or a support contract with an SLA behind the platform itself.
• Pricing: Open source and free to self-host · Paid cloud tiers available.

dokku.com — the original self-hosted "mini-Heroku". Built around Docker and Heroku buildpacks, git push deploys onto a single server with almost no ceremony.

• Best for: developers who want the original Heroku deploy loop reproduced on a single VPS, and teams who appreciate a CLI-first, minimal-web-UI approach to platform administration.
• Consider elsewhere if: you prefer a web UI as the primary interface, or you need built-in multi-host orchestration without stepping up to Kubernetes.
• Pricing: Open source and free to self-host.

Rough pattern that most Heroku migrations follow:

1. Containerise the app first. Every platform above accepts a Dockerfile and this is the artifact most likely to survive future platform changes too.
2. Move the database. Take a fresh dump from Heroku Postgres, restore into the target's managed Postgres or container-based DB. Cut over during a low-traffic window with DNS pointed at both endpoints during the switch.
3. Audit config vars. Heroku config vars accumulate over years — treat migration as a chance to remove ones nobody remembers adding.
4. Decide the runtime model deliberately. If moving to serverless (Vercel), budget time to rework anything that assumed a warm long-running process. If staying on containers, take the opportunity to consolidate background workers and web dynos into a single application topology.
5. Mirror your environments. Formalise dev, staging, and production with clean isolation using the target's workspace / project / environment primitive.

Is Heroku itself still viable? Yes. Still fits teams that have been on it for years and have deep integration with the add-on ecosystem. Teams look elsewhere for cost curves that no longer match the workload, a preference for containers over buildpacks, or a desire to run on infrastructure the team already owns.

Can I combine platforms? Absolutely, and it's more common than the vendor pages suggest. Frontend on Vercel, backend on Suga or Render, background jobs on Fly close to the database, all glued together with the same managed Postgres is a typical modern stack. Pick per workload rather than trying to fit everything onto one platform.

What about AWS, GCP, and Azure directly? Always an option, and for large enterprises with dedicated platform teams they are often the right answer. For everyone else, the raw cloud consoles carry too much undifferentiated infrastructure work for a small team to absorb, so the sensible move is usually a managed PaaS with a BYOC escape hatch.

How should I evaluate free tiers? As evaluation environments, not long-term hosting. Every free tier here has constraints (sleep after inactivity, low resource ceilings, or usage caps) that make sense for kicking the tyres and stop making sense once you have real traffic.

What if I want to change platforms again later? Container-based platforms make this dramatically easier than the buildpack generation, since the deploy artifact is a Docker image any container platform can accept. If portability is a first-order concern, favour platforms that use Dockerfiles as the primary input.