Porter's Two Control-Plane Models, One Codebase

In 2021, Porter launched on Hacker News as "open-source Heroku in your own cloud." Five years later, the homepage doesn't say open source anywhere — and the thing that actually makes a deployment yours, a self-hosted control plane, now sits behind an Enterprise sales call.

That's not a scandal. It's a pricing decision every "self-hosted" PaaS eventually makes, and it's worth looking at closely, because it exposes a distinction most vendors would rather you not draw: running your workloads in your own cloud account is not the same claim as owning your control plane. Porter sells both, under the same product, and the gap between them is the actual price tag on "self-hosted."

What Porter's Two Tiers Actually Buy​

Porter's pricing page lists two ways to run the platform. Read past the marketing copy and they're not two products — they're the same platform with one setting flipped.

The Enterprise row isn't a rewrite of the product. Porter's own pricing copy describes it as "everything in Standard, plus… On-Prem Installation" — an incremental toggle on the same underlying platform, not a fork. That's the "one codebase" half of the story: whether your control plane lives on Porter's infrastructure or yours is a checkbox on an otherwise identical product, not an architectural fork you'd have to migrate between.

Which means the default experience — the one every Standard customer gets, the one most people mean when they say "I use Porter" — is not self-hosted in the sense that matters. Your pods run in your VPC. The thing deciding what runs, when it restarts, and who else can see cluster state runs on Porter's side.

The Generic Tradeoff, Applied to One Vendor​

This split isn't unique to Porter — it's the standard hosted-vs-self-hosted control plane tradeoff that shows up across the Kubernetes-platform space (Civo runs the same two-tier structure for its managed clusters). Stated generally:

• Hosted control plane buys you setup in minutes instead of days, someone else absorbing upgrade and patch risk, and "entire categories of operational failure" (Civo's phrase) engineered out by default. It costs you kubectl access to the control plane itself, the ability to pin operator versions, and — critically for regulated teams — any path to air-gapped or strict-data-residency deployment.
• Self-hosted control plane buys back all of that: direct cluster access, your own upgrade cadence, air-gapped installs, infrastructure choice beyond whatever the vendor's default cloud supports. It costs you the thing the hosted tier was hiding — control-plane availability, the upgrade strategy, the lifecycle management — becomes your team's job, indefinitely.

Porter's Standard/Enterprise split maps onto this exactly, with one twist: the self-hosted side isn't a self-serve toggle. It's gated behind a minimum usage threshold (40 vCPU/80GB) and a sales conversation. A five-person startup running two small services in their own AWS account is, by construction, a Standard customer — which means Porter's control plane, not theirs, decides what happens to their cluster. The "your own cloud" pitch is true and, on its own, incomplete.

The Honest Case for the Default​

None of this makes Porter's Standard tier a bad choice — for most teams reading this, it's probably the right one. A five-engineer startup running two services doesn't want to be the team debugging a wedged etcd cluster at 3am; it wants Porter's SREs to own that pager. Civo's own framing is candid about what the hosted model actually deletes from an operator's job: not just effort, but "entire categories of operational failure" that never get a chance to happen because nobody on the customer side has the access needed to cause them. That's a real trade, not a consolation prize.

The honest version of this article's argument isn't "hosted control planes are bad." It's narrower: a team that picks Standard because it's the only economically sane option below the 40 vCPU/80GB threshold is making an operational-burden decision, not a self-hosting decision — and Porter's own marketing doesn't always keep those two decisions visually distinct. Know which one you're making.

Why "Runs in Your Cloud" Isn't "You Own the Control Plane"​

This is the sleight of hand worth naming, because it's not just Porter's — it's the default structure of the category. "Self-hosted" gets used to describe workload placement (your VPC, your billing account, your IP addresses) far more often than it gets used to describe control-plane ownership (who has cluster-admin, who ships the next upgrade, who sees your logs by default). Those are different axes, and a vendor advertising the first while metering the second isn't lying — it's just letting the ambiguity do marketing work.

Porter's 2021 launch language collapsed that ambiguity in the reader's favor: "open-source Heroku in your own cloud" implied both axes were yours from day one. The 2026 pricing page separates them explicitly, and prices the second one at a sales call plus a usage floor most early customers won't clear. That's not dishonest — the current site makes no open-source claim at all, and the tiering is public. But it does mean the actual price of "self-hosted," for a platform sold this way, is: however much usage it takes to get someone on the phone.

The Threshold, in Real Numbers​

The 40 vCPU/80GB gate is easy to read past, so put a real workload against it. A typical early-stage SaaS running three services — an API, a worker, and a background job runner, each provisioned around 2 vCPU/4GB with a couple of replicas for headroom — lands around 10-14 vCPU and 20-28GB of RAM. That's a third of the way to Enterprise eligibility, running comfortably on Standard, paying roughly $130-180/mo in vCPU charges plus $120-170/mo in RAM charges before cloud-provider costs — and never touching the control plane it doesn't own.

To reach the 40 vCPU/80GB floor organically, that same team needs to roughly triple its footprint — the kind of growth that typically arrives with a Series A and a platform team, not a scrappy three-service MVP. In practice, the self-hosted control-plane conversation doesn't happen until a team has already outgrown the stage where "we don't want to own our control plane" was the honest reason they picked Porter in the first place. By the time self-hosting becomes available, most of the appeal is that the team now might actually want the option — which is either good timing or a coincidence Porter's pricing structure benefits from either way.

The Alternative: One Mode, No Toggle​

A Cluster API-based platform doesn't have a Standard/Enterprise split to begin with, because it doesn't have a hosted-control-plane mode to sell as the default. bex.co targets Cluster API providers directly — Hetzner first, Docker for local dev — which means the control plane that manages your workloads is a Cluster API-managed cluster running on the same machines your app runs on, from the first deploy. There's no tier where bex's own infrastructure holds kubectl access to your cluster, because bex's own infrastructure was never in that position: the project's stated non-goals rule out both a multi-cloud abstraction layer sitting in front of your cloud account and a closed SaaS control plane sitting behind it.

That's a narrower bet than Porter's — one Cluster API provider today, not three clouds — and it's not automatically the right tradeoff for a team that wants a phone number to call at 3am. But it does mean the "self-hosted" claim doesn't need a footnote. There's nothing to upgrade to.

A Checklist for Reading Any "Self-Hosted PaaS" Claim​

Before taking a vendor's self-hosted pitch at face value, ask the two questions Porter's own pricing page answers differently depending on which tier you're reading:

1. Does "self-hosted" describe the workloads, the control plane, or both? If a vendor answers only for workloads, ask the control-plane question directly — it's usually a separate SKU.
2. Is control-plane self-hosting available on every tier, or gated behind Enterprise/sales and a usage minimum? A feature that exists only above a usage threshold isn't a default property of the product — it's an upsell dressed in the product's marketing language.

Applied to Porter: workloads, yes, on every tier. Control plane, only past 40 vCPU and a sales call. Applied to a Cluster API-first platform: both, by construction, on every tier — because there's only one tier.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no Enterprise tier required to own the control plane. Star the repo on GitHub or deploy your first app today.

Sources​

• Porter Pricing.
• Porter homepage.
• Porter Introduction docs.
• Launch HN: Porter (YC S20) – Open-source Heroku in your own cloud.
• Hosted vs. self-hosted control planes — Civo.