Heroku migration targets compared: managed PaaS vs. self-hosted PaaS on your own cloud account

Heroku is winding down as a platform worth betting your infrastructure on, and every team still running production workloads there is now facing a real fork in the road: move to another vendor's managed platform, or run a PaaS layer inside your own cloud account. That choice comes down to control, compliance, cost at scale, and how much operational risk you're willing to hand off. This piece walks through both paths in detail, because picking wrong costs you another migration in two years.

The facts on the ground are stark. Heroku moved to what it calls a sustaining engineering model starting in February 2026: no new features, no new enterprise contracts. Add two outages in June 2025, one multi-hour disruption mid-month followed by another just days later, and you've got a reliability story that's hard to ignore. Meanwhile pricing crept upmarket, and basic dynos cost a lot more than they used to, with the free tier gone entirely. For teams still on Heroku, the real question has shifted from whether to leave to where to land.

The three migration archetypes and where this piece focuses

There are really three paths off Heroku, and it's worth naming all three before we zoom in.

First: fully managed third-party PaaS, think Render, Railway, Fly.io, DigitalOcean App Platform, or Vercel. Second: bring-your-own-cloud PaaS, where a vendor's control plane sits on top of your own AWS, GCP, or Azure account. Third: open-source self-hosted tools like Dokku or Coolify, which are the cheapest option in raw infrastructure cost but demand the most operational attention.

This piece focuses on the first two. That's the fork most teams actually face when they want the simplicity of a PaaS without rebuilding their deployment pipeline from scratch. Open-source self-hosted deserves a mention because it's a legitimate option for small teams with an engineer willing to own server maintenance full time, but it sits outside the scope of a comparison built around teams evaluating platforms rather than DIY projects.

The reason this matters as an architectural decision, not just a line item on a spreadsheet, is structural. Managed PaaS and own-cloud PaaS put your workloads in fundamentally different places, and that placement ripples into everything else: who can see your data, what you pay at scale, and what happens when something breaks at 2 a.m.

What managed PaaS platforms actually offer and where they stop

The core promise hasn't changed since Heroku popularized it in the late 2000s: push your code, get a URL back. No cluster to manage, no cloud account to configure, no infrastructure team required, and for a lot of teams, that's still exactly what they need.

Railway bills by the second and has SOC 2 Type II and HIPAA certification, plus genuinely good developer ergonomics. Yet it's had repeated platform outages, which makes it a harder sell for anything user-facing and revenue-critical. Render takes the opposite pricing approach, flat and predictable, and it's the only one of these core alternatives with built-in DDoS protection out of the box. It runs on top of AWS and GCP, offers managed Postgres, and has a HIPAA-enabled workspace on its higher-tier plans.

Fly.io is architecturally different from the rest: it runs on bare-metal servers distributed globally rather than sitting on top of a traditional cloud provider, and that shows up in meaningfully lower egress costs at scale compared to Railway. The tradeoff is that Postgres on Fly isn't fully managed, so some database maintenance still lands on your team.

DigitalOcean App Platform is worth calling out specifically for Heroku refugees: it's built on Cloud Native Buildpacks, the same underlying architecture Heroku itself uses, so a Procfile-based app migrates over with minimal rework. It has a free tier, and DigitalOcean has recently added outbound VPC integration and MCP server deployment for teams building AI workflows. Vercel, meanwhile, is optimized specifically for frontend work and Next.js: serverless, scales to zero, but since it runs on AWS under the hood, that overhead shows up in what you pay.

Here's the ceiling all five share, though: your workloads run inside the vendor's infrastructure, not yours. That's fine until it isn't, and it isn't fine the moment you care about data residency, private networking, or proving to an auditor exactly where your customer data lives.

What "bring your own cloud" PaaS actually means architecturally

BYOC sounds like a marketing term, but it describes something concrete. In a real bring-your-own-cloud setup, the workload data plane runs inside your own cloud account, whether that's AWS, GCP, or Azure. User traffic hits your VPC directly, while the vendor manages a control plane, the dashboard, the deployment logic, the orchestration, without ever sitting in the actual request path.

What that means practically: your workloads, your databases, and your secrets never leave your account. The vendor literally cannot see the payload of a request hitting your application, and your infrastructure bill comes directly from your cloud provider at standard rates, not marked up through a middleman.

Heroku's original sin, if you can call it that, was abstracting the underlying cloud away entirely. That's what made it fast to start with back in the day, and it's also exactly what makes it frustrating once you need static IPs, private networking, or a specific data residency guarantee for a customer contract. Own-cloud PaaS gives you back the parts of Heroku people actually loved, the dashboard, the CLI, preview environments, one-click add-ons, while keeping the actual infrastructure inside your own perimeter.

None of this is free, to be clear. You need a cloud account with real spend behind it, and there's setup involved that a fully managed platform skips entirely, so anyone promising a zero-config path here is selling something.

How the main own-cloud PaaS options compare in practice

Porter is the clearest example of this model done well. It deploys into AWS, GCP, or Azure, provisions a Kubernetes cluster underneath, and wraps the whole thing in a dashboard and CLI that feels a lot like using Heroku. It covers the full lifecycle: CI/CD, preview environments, managed add-ons, autoscaling, GPU workloads for teams doing ML work, automatic CVE patching, and one-click SOC 2 and HIPAA compliance automation. Pricing is resource-based and transparent, since you're paying for what you actually provision. There's a dedicated startup program for earlier-stage teams too, and Porter has become a common landing spot for AI startups that need GPU infrastructure without hand-rolling their own Kubernetes tooling.

Worth noting: both of these run Kubernetes underneath the hood, but neither one asks you to manage the cluster yourself. That's the actual distinction between an own-cloud PaaS and just running raw Kubernetes on your own, and the platform layer absorbs upgrades, patching, and config so your team isn't the one staring at a kubectl output at midnight.

Open-source self-hosted tools like Dokku and Coolify sit at the far end of this spectrum. They're the cheapest option in terms of raw infrastructure spend, since there's no platform fee at all, but the full weight of server operations sits on your team. That's a fine tradeoff for a small team with one engineer who genuinely wants to own it, though the calculus shifts once you're past the earliest stage of growth.

Where the cost math diverges as you scale

Managed PaaS pricing bakes convenience into the unit cost. You're paying the vendor's margin stacked on top of the underlying cloud compute they're using, and egress pricing in particular varies a lot from platform to platform.

At low scale, managed PaaS usually wins on total cost. There's no platform fee to speak of, no cloud account overhead to set up, and the simplicity is worth the modest premium. But the economics shift as workloads grow, and own-cloud PaaS bills your infrastructure straight to your cloud account at standard rates, which means you're the one capturing reserved instance pricing, savings plans, and committed-use discounts. On a managed platform, the vendor captures those discounts instead, and you never see them.

Heroku bills at scale can run into the tens of thousands of dollars a month. Teams leaving Heroku at that spend level have the most to gain by moving their infrastructure cost back into their own cloud account, where they control the discount structure.

CI/CD spend tells a similar story. Small teams fit comfortably inside free tiers on most CI providers, but organizations running significant build volume can end up spending anywhere from a few thousand to tens of thousands of dollars a year on CI/CD tooling alone, sometimes reaching $50,000 annually. Own-cloud platforms that fold CI/CD into the base platform fee change that math meaningfully.

There's no universal crossover point here, and I won't pretend there is. It depends on compute density, how much data you're pushing out in egress, and how much reserved capacity your team is comfortable committing to. The real question worth asking is at what scale the model flips in your favor, and that's a number you can actually calculate against your own usage.

How compliance requirements change the decision before you pick a platform

SOC 2 Type II is close to a hard requirement now if you're selling SaaS to enterprise customers; most Fortune 500 procurement teams simply won't sign without it. The audit itself commonly runs into the tens of thousands of dollars, and it requires your controls to actually operate correctly over an observation period, not just exist on paper.

On the managed PaaS side, Railway carries SOC 2 Type II certification, and Render offers SOC 2 Type II along with a HIPAA-enabled workspace on its Organization and Enterprise plans. These are real, legitimate certifications, but read the fine print: they cover the vendor's own infrastructure, not your specific deployment configuration sitting on top of it.

That's the gap. On shared-tenant managed PaaS, your workloads share infrastructure with other customers, and your data residency and network isolation depend entirely on how the vendor built their system. The audit evidence covers the platform, not your environment specifically.

On own-cloud PaaS, compliance posture is scoped to your own VPC, which means your auditors can walk through your actual environment directly. Porter's one-click SOC 2 and HIPAA automation configures controls inside your account rather than inheriting them from a shared platform underneath you. For teams handling PHI, sensitive PII at any real scale, or selling into regulated industries, that difference removes the hardest compliance questions before they ever become audit findings.

If you're not facing any of this in the next year or so, skip ahead; none of this changes your decision today. But if compliance is coming in the next 12 to 18 months, factor it in now, since migrating twice is expensive.

Operational risk: what each model asks of your engineering team

The managed PaaS pitch is genuinely true: no cluster upgrades, no CVE patching, no infrastructure on-call rotation. The platform absorbs all of it, and for a small team, that's real time saved.

The risk side is just as real, though. When the platform itself goes down, and Railway and Heroku have both demonstrated this isn't hypothetical, your team has no lever to pull. You wait, and that's the deal you signed up for, whether you thought about it that way or not.

Own-cloud PaaS moves the locus of control back to you. Your infrastructure lives in your account, so a control-plane issue on the vendor's side doesn't take down your actual running workloads. The tradeoff is that cluster upgrades and CVE patches still need to happen somewhere; platforms like Porter automate both, so it's not manual toil, but the responsibility structure is different.

The question worth asking your team directly is simple: when something breaks, what do we actually own? On managed PaaS, the answer is often that you wait on the vendor's status page. On own-cloud PaaS, the answer is that you have access to the infrastructure and can act. Preview environments, zero-downtime deploys, rollback, these are table stakes on both sides at this point, so the real difference isn't day-to-day developer experience, it's what happens on a bad day.

Neither model requires a dedicated DevOps hire to run well, but if you're going the own-cloud route without one, look specifically for a platform built for that constraint, not one that assumes you already have infrastructure expertise on staff.

A decision framework for picking your migration target

Go managed PaaS if you're early-stage, your compute spend is still small, you have no compliance requirements on the near horizon, and you want zero infrastructure setup so you can get back to building product. Time-to-migrate matters more than long-term cost optimization at this stage, and that's a completely reasonable priority.

Go own-cloud PaaS if you're approaching or past the point where managed PaaS pricing shows up as a real line item on your budget, if you handle regulated data or sell into enterprise accounts, if you need data residency guarantees you can actually prove, or if you simply don't want your infrastructure's fate tied to another company's product roadmap decisions.

Heroku's own trajectory is the case study here. A sustaining engineering model is what happens when you build your entire stack on a platform you don't control and the vendor's priorities shift out from under you. Own-cloud PaaS is the structural answer to that exact risk, since the infrastructure stays yours regardless of what any vendor decides to do next.

The migration mechanics themselves barely change based on which path you pick. Web dynos become web services, worker dynos become background workers, Scheduler jobs become cron jobs, and that mapping holds pretty much everywhere. The database migration is the highest-risk step no matter which target you choose: use pg_restore or psql with an actual maintenance window scheduled, verify your Postgres extensions and version match before cutover, and watch your logs and error rates closely for the first 48 hours after you flip DNS.

One last thing worth knowing: this decision isn't permanent in the own-cloud direction. Your infrastructure sits in your account, so if you want to swap control planes later, you can, since the underlying workloads never moved. Managed PaaS is stickier by nature, because your data and your running workloads live inside the vendor's environment the whole time. Choose accordingly.