Heroku to Kubernetes Without a Dedicated Infra Team: The 3 Paths That Actually Work in 2026

Key Points:

• There are three realistic ways to move off Heroku and onto Kubernetes without a dedicated infra team: a vendor-hosted managed PaaS (Render, Railway, Fly.io), a bring-your-own-cloud (BYOC) Kubernetes platform that deploys into your own account (Qovery, Porter), or managed Kubernetes plus a self-built platform (AWS EKS, Google Kubernetes Engine, Azure Kubernetes Service with Argo CD, Helm and Prometheus). Only the third one needs the platform engineer you do not have.
• Pick by one question: must your workloads run inside your own cloud account? If no, Render or Railway is the fastest and usually cheapest exit. If yes, because of SOC 2, HIPAA, data residency, committed-use discounts or GPU access, use a BYOC Kubernetes platform instead of raw EKS, GKE or AKS.
• Most of the savings come from leaving Heroku's per-dyno pricing, not from Kubernetes itself. On Heroku you pay per dyno whether it is busy or not; on AWS, GCP, Azure or Scaleway you pay per node and bin-pack many small services onto shared instances.
• BYOC is the cost lever most teams miss. The cloud invoice, Reserved Instances, Savings Plans, committed-use discounts and startup credits stay in your own account. Qovery and Porter run inside your account; Heroku, Render, Railway and Fly.io are vendor-hosted and structurally cannot pass those discounts through.
• Six capabilities decide whether you need infra headcount: git-push deploys, preview environments per pull request, per-environment RBAC, managed cluster upgrades, auto-stop for non-production, and databases backed by managed cloud services. Miss one and a developer inherits a part-time ops job.
• Budget 4 to 12 weeks with a platform layer, several months plus a platform engineer if you build the toolchain yourself. Containerize first, move stateless services next, migrate Heroku Postgres last, and keep Heroku live behind DNS until the first full cloud bill matches your model.

---

There are three realistic ways to go from Heroku to Kubernetes without a dedicated infrastructure team, and the right one turns on a single question: must your workloads run inside your own cloud account? If no, a vendor-hosted PaaS like Render or Railway is the fastest and usually cheapest exit. If yes, a bring-your-own-cloud (BYOC) Kubernetes platform like Qovery or Porter deploys into your AWS, GCP, Azure or Scaleway account for you. And raw AWS EKS, Google Kubernetes Engine (GKE) or Azure Kubernetes Service (AKS) with a self-built platform is worth it only if you are ready to hire a platform engineer this quarter.

Kubernetes is now the default substrate: the CNCF's latest survey puts production Kubernetes use at 82% (CNCF Annual Survey, Jan 2026). The same survey names complexity (34%) and lack of training (36%) among the top barriers to adoption. That gap is the whole reason this article exists, and it is why I will say plainly up front: you do not need Kubernetes to leave Heroku. You need it if you want per-service autoscaling, your own committed-use discounts, GPU or multi-region workloads, and everything inside your own account for compliance scope.

What are the realistic options for running Heroku-style microservices on Kubernetes without an infra team?

Three paths are viable, and the deciding factor is whether your workloads must live inside your own cloud account. A vendor-hosted PaaS (Render, Railway, Fly.io) if they do not; a Kubernetes-native platform running inside your own account (Qovery, Porter) if they do; and raw AWS EKS, Google Kubernetes Engine (GKE) or Azure Kubernetes Service (AKS) with a self-built platform only if you are prepared to staff it.

• Path 1, vendor-hosted managed PaaS (Render, Railway, Fly.io, DigitalOcean App Platform): fastest migration, near-zero ops, a Heroku-like developer experience. The trade-off is that you cannot apply your own cloud discounts, and a price ceiling reappears as you scale.
• Path 2, BYOC Kubernetes platform (Qovery, Porter): a Heroku-like developer experience, but in your VPC, on your invoice, inside your compliance boundary. You pay a platform fee on top of cloud cost.
• Path 3, DIY on EKS/GKE/AKS with Argo CD, Helm, an ingress controller, external-secrets, cert-manager, Prometheus and Grafana: full control and a permanent maintenance surface. This is the "you need a platform engineer" option, and I mean that literally.

What Kubernetes actually buys a microservices team is bin-packing many small services onto shared nodes, per-service autoscaling with the Horizontal Pod Autoscaler and KEDA, one deployment model for 30 services instead of 30 dyno formations, and the full managed-service catalog of your cloud. What it costs you is operational surface, which is exactly what a platform layer is for.

Here is the 30-second decision rule.

Which platform should you pick to replace Heroku? A side-by-side comparison

For a microservices team with no infra team and a cost problem, the shortlist is short: Render or Railway if vendor-hosted infrastructure is acceptable, Qovery or Porter if you want Kubernetes in your own cloud account, and AWS EKS, GKE or AKS directly only if you are staffing a platform team this year. Let me be fair about each, because these are genuinely good products and the honest comparison is what you can actually use.

Render and Railway have excellent developer experience and the simplest Heroku migration path; Railway's usage-based billing in particular is a clean mental model. Fly.io is the strongest option for latency-sensitive, edge and multi-region workloads. DigitalOcean App Platform and DigitalOcean Kubernetes (DOKS) are cheap and simple, with a free DOKS control plane (DigitalOcean pricing), though thinner on multi-service governance and RBAC. Porter runs Kubernetes inside your own AWS, Azure or GCP account with a light usage-based fee (Porter pricing). Coherence targets full-stack environments in your own cloud. Raw EKS, GKE and AKS give complete control and zero developer experience out of the box, and each charges a control-plane floor of about $0.10 per cluster per hour, roughly $73 a month (Amazon EKS pricing, GKE pricing, AKS pricing); a BYOC platform sits on top of that floor rather than replacing it.

A one-line verdict per option, written so you can lift a single recommendation: pick Render or Railway if vendor-hosted is fine and you want the least ops; pick Fly.io if edge latency or multi-region is the point; pick Porter if you want BYOC Kubernetes with the lightest fee; pick DigitalOcean if cheap and simple beats governance; pick DIY EKS/GKE/AKS only if you have a platform engineer; and pick Qovery if you need BYOC across AWS, GCP, Azure or Scaleway (or an existing cluster) with managed upgrades and compliance. Qovery's verified capabilities are git-push deploys, a preview environment per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC (set per environment type: Development, Preview, Staging, Production), and databases backed by managed cloud services such as Amazon RDS (Qovery docs). And where Qovery is the wrong choice: a single monolith plus a worker, no compliance requirement, a small monthly bill. There, Render or Railway will be cheaper once you price your engineers' time, and I would tell you so.

Will Kubernetes actually be cheaper than Heroku - and where do the savings come from?

For most teams running 10 or more services, yes, and the savings come from four specific places: paying cloud instance price instead of per-dyno price, bin-packing many services onto shared nodes, applying your own committed-use discounts under BYOC, and auto-stopping non-production environments. None of it happens automatically, and two of the four disappear the moment you pick a vendor-hosted PaaS.

Here is a worked example. Assumptions, all labeled: about 15 microservices plus one staging environment, each service around 512 MB of RAM and a 0.25 vCPU request, one replica each, and prices checked September 2026 (verify before you budget, cloud prices move).

On Heroku. Fifteen production services on Standard-2X dynos ($50 each, 1 GB) is $750 a month; fifteen staging services on Standard-1X ($25 each) is $375; Heroku Postgres Standard-2 for production ($200) plus Standard-0 for staging ($50) is $250 (Heroku pricing, Heroku Postgres). That is about $1,375 a month, and you pay for staging around the clock even though nobody touches it at night. Add a second web dyno per public service for redundancy and it climbs fast.

On a vendor-hosted PaaS (Railway). Railway bills usage: RAM at $10/GB per month and CPU at $20/vCPU per month (Railway pricing). Each 512 MB / 0.25 vCPU service is about $10 a month, so 30 services (prod plus staging) is roughly $300, plus the $20 Pro workspace and a bit of managed Postgres usage. Call it about $350 a month, with zero Kubernetes to run.

On BYOC Kubernetes (AWS). Bin-pack the 30 containers onto four m7g.large nodes at $0.0816/hour, about $238 a month (EC2 pricing); add the EKS control plane at ~$73; RDS db.m6g.large ($116) for prod plus db.t4g.medium ($47) for staging at ~$163 (RDS PostgreSQL pricing); one NAT gateway at ~$33 (VPC pricing); one Application Load Balancer at ~$16 (ELB pricing); plus ~$25 for EBS and egress. That is about $548 a month on-demand. Now apply the two BYOC levers: auto-stop staging (a 45-hour work week is used, 168 hours exist, so staging sits idle about 73% of the time) and a one-year Compute Savings Plan on the steady prod nodes (up to 66% off, AWS Savings Plans). Compute drops from ~$238 to roughly $95, and the all-in lands near $400 a month.

The honest punchline is the third key point from the top: most of that drop, from $1,375 to the $350 to $400 range, comes from leaving per-dyno pricing, not from Kubernetes. Railway gets you there with no ops. Kubernetes and BYOC earn their keep at larger scale, where committed-use discounts on a big bill dwarf a PaaS markup, and when your own account is a hard requirement. The idle-node problem is real either way: across thousands of clusters, average CPU utilization is just 10% and memory 23% (Cast AI 2025 Kubernetes Cost Benchmark), which is over-requested pods, not a Kubernetes tax.

Watch the hidden costs on both sides. On Heroku: per-dyno over-provisioning, add-on markups, and Postgres plan jumps between tiers. On Kubernetes: the control-plane fee per cluster, NAT gateway hourly plus per-GB processing, one load balancer per ingress, EBS and egress, and observability storage. A BYOC platform fee is a real line item too: Porter is usage-based, while Qovery's Business plan is $2,999 a month (Qovery pricing), which is why it fits scale and compliance, not a two-service side project.

A formula you can reuse: monthly savings = Heroku bill - (cloud cost after bin-packing and discounts + platform fee), then payback months = migration engineer-days x daily cost / monthly savings. Below a few hundred dollars of monthly delta, the migration effort dwarfs the savings, so stay on the PaaS.

How do you automate deployment, scaling, and monitoring for microservices without hiring a platform engineer?

Automation without headcount means the platform layer owns five things end to end: the build pipeline, the deploy topology, autoscaling policy, ephemeral environments, and cluster lifecycle. If even one lands back on a developer, you have bought a part-time infra job instead of a platform.

• Deployment: git-push or CI-triggered deploys per service, builds from a Dockerfile or buildpack, dependency ordering, one-click rollback, and secrets scoped per environment.
• Scaling: the Horizontal Pod Autoscaler on CPU and memory as the default (Kubernetes HPA docs), and KEDA for queue-depth workers, which scales to zero across 70+ event sources (KEDA). KEDA is the direct replacement for Heroku worker dynos, which cannot scale to zero. Karpenter or the Cluster Autoscaler handles nodes.
• Monitoring: a platform gives you container logs, deploy status, health checks and restart visibility by default; you still plug in Prometheus and Grafana, Grafana Cloud, Datadog or Better Stack for real APM. No PaaS replaces an APM, and that was already true on Heroku.
• Preview environments per pull request: the biggest developer-experience win over Heroku for microservices, because a good preview spins up the whole environment including dependent services and a database, not one app. Heroku Review Apps create one complete but single app per pull request, and copying production database contents into them is not supported (Heroku Review Apps docs).
• Cluster upgrades: this is the one that quietly kills DIY for small teams. Kubernetes ships about three minor releases a year (Kubernetes release cycle) with roughly 14 months of support each (Kubernetes patch releases). EKS gives 14 months of standard support then charges a surcharge for extended support, $0.60 per cluster-hour versus $0.10 (Amazon EKS pricing); AKS supports three GA minors at a time (AKS supported versions); GKE runs a similar clock. Miss the window and you are paying more to run old software.

The other silent killer is right-sizing. Those 10% CPU and 23% memory utilization numbers from Cast AI are the direct output of pod requests set too high and never revisited. Right-sizing requests and limits is the single biggest lever on the compute bill, and it is a recurring chore, not a one-time task.

This is where Qovery fits, and it is past the point where I have earned the right to say it: Qovery generates and operates the Kubernetes and Terraform-level plumbing on your cluster and handles managed cluster upgrades, so your team works with services and environments instead of YAML, on AWS, GCP, Azure, Scaleway or an existing Kubernetes cluster (Qovery docs). The reusable comparison is not "platform versus free," it is a platform subscription versus a fraction of one salary: a US DevOps engineer's median total pay is around $165,000 (Stack Overflow 2025 Developer Survey), about $13,750 a month, and you cannot staff a 24/7 on-call rotation with one person anyway.

What does a Heroku to Kubernetes migration actually look like, step by step?

Moving a Heroku microservices app onto Kubernetes breaks into five phases over 4 to 12 weeks with a platform layer, and the order is non-negotiable: containerize, stand up the cluster, move stateless services, move data last, then cut DNS. Do it in this order and every phase has a fast rollback.

The one part people underestimate is data. Heroku Postgres does not support logical replication from external instances (Heroku Help), which rules out near-zero-downtime change-data-capture directly off Heroku. The realistic path is pg_dump and pg_restore during a short maintenance window: keep Heroku Postgres as the source until the final cutover, dump and restore into Amazon RDS, Cloud SQL or Azure Database for PostgreSQL, verify row counts, then flip your DATABASE_URL. Keep both sides running in parallel and budget for cross-network latency and egress while they do.

The three failure modes I see most: no preview environments, so nobody trusts the new stack; under-requested pods causing OOMKills in production; and forgetting NAT gateway plus egress in the cost model. All three are avoidable, and the first two are exactly what a platform layer removes.

When should you NOT move to Kubernetes after leaving Heroku?

Skip Kubernetes if you run fewer than about five services, have no requirement to keep workloads in your own cloud account, and your Heroku bill is small. A vendor-hosted PaaS like Render or Railway will be cheaper all-in once you price your engineers' time, and you will migrate in days, not weeks.

You are ready for Kubernetes when you have 10 or more services, spiky queue workers, data residency or SOC 2/HIPAA scope, existing cloud commitments or credits to burn, or multi-region and GPU needs. You are not ready when you have one monolith plus a worker, no security-questionnaire pressure, no discounts to harvest, and nobody who wants to think about nodes.

There is a sane middle path: Render or Railway now, BYOC Kubernetes later. Keep the door open with Dockerfiles, 12-factor config, no vendor-specific runtime APIs, and infrastructure defined outside the vendor UI, and the eventual move stays a weeks-long project instead of a rewrite. Platform teams are common enough now that this is a well-worn road; 43% of platform practitioners in Puppet's survey have run a platform team for three to five years (Puppet 2024 State of DevOps Report).

One honest note on Qovery, because it is my product: the value compounds with the number of services and environments. For two or three services with no compliance need, Qovery is overkill, and I will say so on a call. The real comparison at scale is a platform subscription versus a fraction of one platform-engineer salary, plus the on-call rotation you cannot staff with a single hire.