DEV Community: hidde

Heroku Is in Sustain Mode. Here Are Your Real Options in 2026

hidde — Thu, 05 Mar 2026 14:27:42 +0000

After 16 years, Heroku stopped building. Where do you actually go?

On February 6, 2026, Salesforce moved Heroku into sustain mode. No new features. Maintenance and security patches only. The platform that taught a generation of developers to git push heroku main is done evolving.

If you're still on Heroku, you need a plan. If you already left for Railway or Render, it's worth asking whether you solved the underlying problem, or just moved to a younger version of the same model.

What actually happened to Heroku

Salesforce acquired Heroku in 2010 for $212 million. For a while, investment continued. Then it slowed. Then it stopped.

The timeline:

2022: Free tier removed. Community trust damaged.
2023 to 2025: Feature development slowed to a crawl. No significant platform updates.
February 2026: Sustain mode officially announced. The Heroku team is reassigned. Platform stays running but gets no new features.

Heroku isn't shutting down. Your apps will keep running. But you're now on a platform that will slowly fall behind on runtime versions, security patches, and ecosystem support. The question isn't whether to migrate, it's when and where.

The migration options, honestly evaluated

Option 1: Another shared PaaS (Railway, Render, Fly.io)

Railway is the most common destination. Good DX, active development, $100M in funding. Railway-level experience is genuinely excellent for small-to-medium projects.

Render offers straightforward deployment with a generous free tier. Predictable pricing. Good docs.

Fly.io focuses on edge deployment and global distribution. More complex than Railway or Render, but powerful for latency-sensitive applications.

The problem with this option: you're solving the same risk with the same architecture. Shared PaaS means your infrastructure lives on someone else's servers. If Railway changes direction, raises prices dramatically, or gets acquired, you're in the same position you're in now with Heroku.

This already happened once. It can happen again.

Option 2: BYOC (Bring Your Own Cloud)

BYOC platforms deploy to your cloud account. You get the push-to-deploy DX of a PaaS, but your containers, databases, and data live in your own AWS or GCP account.

If the BYOC vendor disappears tomorrow, your infrastructure stays. Your GKE clusters, your RDS databases, your Cloud SQL instances, they're just standard cloud resources in your account.

The platforms:

AZIN: GCP BYOC via GKE Autopilot. No Kubernetes knowledge required. First cluster free. Full Heroku migration guide.
Porter: AWS, GCP, Azure via managed Kubernetes. ~$225/month minimum on AWS.
Flightcontrol: AWS-only via ECS. No Kubernetes. Free tier available.
Northflank: Six cloud providers. BYOC on all plans including free tier.

For a detailed comparison: Best Heroku Alternatives in 2026

Option 3: Self-hosted (Coolify, Kamal, Dokku)

Install a PaaS on your own servers. Maximum control, maximum responsibility.

Coolify is the most popular (50K+ GitHub stars). Web dashboard, 280+ one-click services. You manage the servers.

Kamal is from 37signals (Basecamp/HEY). Docker deployment via SSH. No web UI. CLI-only.

Dokku is the original Heroku alternative. Proven, stable, single-server.

Great if you're comfortable managing Linux servers and want the lowest possible cost. Not great if you want managed databases, auto-scaling, or zero-downtime deploys out of the box.

Option 4: Go full cloud-native (ECS, GKE, EKS directly)

Skip the abstraction layer entirely. Deploy containers directly to AWS ECS, Google GKE, or manage your own Kubernetes. Full control. Full complexity.

This makes sense if you have a dedicated DevOps team. It doesn't make sense if your developers are also your ops team, which is most startups and small companies.

The actual migration process

Regardless of where you go, the migration follows the same pattern:

Inventory your Heroku resources. List every app, addon, and config var. Check for Heroku-specific dependencies (Heroku Postgres, Heroku Redis, Heroku Scheduler).

Containerize if you haven't. Most Heroku apps use buildpacks. If your app doesn't have a Dockerfile, create one. Most modern platforms support buildpack-style auto-detection, but a Dockerfile gives you the most portability.

Migrate databases first. This is the hardest part. Heroku Postgres to Cloud SQL, RDS, or self-managed Postgres. Use pg_dump/pg_restore for small databases. For larger databases with zero-downtime requirements, set up logical replication first, then cut over.

Deploy to the new platform in staging. Push your code to the new platform. Verify it works. Run your test suite against it. Check environment variables, build steps, and runtime behavior.

Switch DNS. Once staging is verified, point your domain at the new deployment. Monitor for 24 to 48 hours before tearing down the Heroku app.

Cancel Heroku. Remove addons first (they often have separate billing). Then delete apps. Then downgrade your account.

Which option should you pick?

If you want the fastest migration with the least change: Railway or Render. Same deployment model as Heroku. Lowest learning curve.

If you want to own your infrastructure and never be in this position again: BYOC (AZIN, Porter, Flightcontrol, Northflank). More setup upfront. Better long-term position.

If you want maximum control at minimum cost: Coolify or Kamal on a VPS. Requires server management skills.

If you have a DevOps team: Raw cloud services (ECS, GKE). Skip the abstraction.

The one option I'd avoid: staying on Heroku and waiting. Sustain mode means the platform will slowly degrade. Runtime versions will fall behind. Security patches will be slower. The longer you wait, the more technical debt accumulates.

The Heroku era was good. It's over. Pick your next platform based on where you want to be in three years, not just what's easiest today.

6 BYOC Cloud Platforms That Deploy to Your Own AWS or GCP Account (2026)

hidde — Thu, 05 Mar 2026 14:16:26 +0000

I spent two weeks testing every BYOC (Bring Your Own Cloud) platform I could find. BYOC means a platform deploys your apps into your cloud account, your AWS, your GCP, while managing the operational complexity for you. You own the infrastructure. They own the developer experience.

Here's what I found.

Why BYOC instead of Railway/Render/Heroku?

Three reasons:

Cost. Shared PaaS platforms add margin on compute. At $500+/month, you're paying significantly more than cloud-direct pricing. BYOC lets you use reserved instances and startup credits.
Compliance. SOC 2 and GDPR audits are way easier when you point auditors at your own CloudTrail logs instead of depending on a vendor's SOC 2 report.
No vendor lock-in on infrastructure. If you leave a shared PaaS, your infrastructure doesn't come with you. With BYOC, your cloud resources stay in your account.

The platforms

1. AZIN: GCP BYOC, no Kubernetes overhead

Clouds: GCP (AWS and Azure on roadmap)
BYOC model: GKE Autopilot, first cluster free, pay per pod
Min cost: Platform fee + GCP costs (no cluster overhead)

AZIN gives you a Railway-like push-to-deploy experience, but your containers run in your GCP account on GKE Autopilot. The key differentiator: GKE Autopilot's first cluster is free and you pay only for pod resources. No EKS control plane fee. No idle nodes.

You push code, AZIN builds it (using Railpack, an open-source builder), deploys it, handles TLS and networking. Everything is visible in your Google Cloud Console.

Best for: Teams on GCP who want the simplest BYOC experience with the lowest cost floor.
Limitation: GCP only for now. If you need AWS or Azure today, look at Porter or Flightcontrol.

Full comparison of all BYOC platforms: azin.run/blog/best-byoc-cloud-platforms

2. Porter: Managed Kubernetes on all three clouds

Clouds: AWS (EKS), GCP (GKE), Azure (AKS)
BYOC model: Managed Kubernetes clusters in your account
Min cost: ~$225/month on AWS (EKS control plane + nodes)

Porter provisions and manages a full Kubernetes cluster in your cloud account. You deploy through a Heroku-like UI. Under the hood: real K8s with all the power and all the operational overhead managed for you.

The catch: Kubernetes clusters have a base cost. On AWS, the EKS control plane is ~$75/month, plus node instances. The minimum practical bill before deploying anything is roughly $225/month.

Best for: Teams that want multi-cloud BYOC and are comfortable with the K8s base cost.
Limitation: High cost floor on AWS. GitHub-only for source integration.

3. Flightcontrol: AWS-only, ECS-based

Clouds: AWS only
BYOC model: ECS + CloudFormation in your account
Min cost: $0 (free tier: 1 service, unlimited deploys)

Flightcontrol skips Kubernetes entirely. It deploys to your AWS account using ECS (Elastic Container Service) and Fargate. Infrastructure is provisioned via CloudFormation, standard AWS primitives. If you stop using Flightcontrol, your AWS resources remain as-is.

All 28 AWS regions are supported. IAM AssumeRole for access, clean and auditable.

Best for: AWS-native teams who don't want Kubernetes.
Limitation: AWS only. Preview environments require the $397/month Business plan. Small team (~6 people).

4. Northflank: BYOC across six clouds

Clouds: AWS, GCP, Azure, Oracle, Civo, CoreWeave
BYOC model: Managed Kubernetes + BYOK (bring your own K8s cluster)
Min cost: $0 (free Developer Sandbox: 1 BYOC cluster)

Northflank has the broadest cloud coverage of any BYOC platform. They also support bringing existing Kubernetes clusters (BYOK), which is unique. BYOC is available on all plans, including the free tier.

The platform itself is full-featured: CI/CD, managed databases, per-second billing, preview environments.

Best for: Teams that need BYOC across multiple cloud providers or have existing K8s clusters.
Limitation: Steeper learning curve. The free tier limits you to 1 BYOC cluster.

5. Qovery: Terraform-based BYOC

Clouds: AWS, GCP, Azure
BYOC model: Terraform + Kubernetes in your account
Min cost: $0 (free tier: 1 cluster, 1 project)

Qovery uses Terraform to provision Kubernetes clusters in your cloud account. It targets platform engineering teams that want a self-service developer portal on existing infrastructure. Per-seat pricing on paid plans ($29/user/month).

Best for: Platform engineering teams managing multiple environments.
Limitation: Terraform dependency adds complexity. Per-seat pricing scales poorly for larger teams.

6. Defang: Docker Compose to your cloud

Clouds: AWS, DigitalOcean (GCP coming)
BYOC model: Docker Compose → ECS
Min cost: Free (beta)

Defang takes a standard docker-compose.yml and deploys it to your cloud account. If your local dev uses Docker Compose, this is the fastest path to production in your own cloud. Still in beta.

Best for: Docker Compose workflows that need to move to production.
Limitation: Beta. No managed databases. Limited to Compose workflows.

Quick comparison

Platform	Clouds	Min cost	Managed DBs	No K8s needed
AZIN	GCP	Platform fee + GCP	Yes	Yes
Porter	AWS/GCP/Azure	~$225/mo (AWS)	Yes	Yes
Flightcontrol	AWS	$0 (free tier)	Yes (RDS)	Yes
Northflank	6 clouds	$0 (free tier)	Yes	Yes
Qovery	AWS/GCP/Azure	$0 (free tier)	Yes	No (Terraform)
Defang	AWS/DO	Free (beta)	No	Yes

What about Railway, Render, and Heroku?

Railway has BYOC, but it's Enterprise-only with pricing not publicly listed.

Render does not offer BYOC at any tier.

Heroku entered sustain mode in February 2026. No new features. If you're still on Heroku, the migration question is when, not if, and BYOC is worth considering over jumping to another shared PaaS.

When shared PaaS is still fine

If you're building a side project, prototyping, or your monthly compute is under $100, shared PaaS (Railway, Render) is simpler and sufficient. BYOC makes sense when compliance, cost at scale, or infrastructure ownership starts mattering.

The crossover point is roughly $300-500/month in compute spend. Above that, BYOC saves money. Below that, it's an operational overhead you don't need yet.