BYOC Bills Twice: Porter's $20M Bet on Your Cloud Account vs Owning the Bare Metal

In January 2026, Porter raised a $20M Series A led by FirstMark Capital to make "using the public cloud utterly seamless." The YC S20 company's pitch is seductive: Heroku-style deploys on Kubernetes that runs in your own AWS, GCP, or Azure account. But Porter's own pricing page carries the most honest sentence in the BYOC business: when asked whether the price includes the underlying cloud, the FAQ answers flatly — no, it does not.

You pay Porter for the PaaS, and then you pay Amazon for the computers. Two meters, one workload.

Here is what that double bill actually totals for a typical small-team workload — two web services, a worker, and staging, requesting 4 vCPU and 8 GB RAM — versus running the same workload on a single owned bare-metal box:

Same apps, roughly a 7x gap. The rest of this post itemizes both columns, shows where the gap narrows and widens, and argues that "runs in your account" and "runs on machines you own" are not two flavors of sovereignty — they are different cost shapes entirely.

How Porter actually works​

Porter's model dates to its 2021 Launch HN debut as "open-source Heroku in your own cloud." Connect your cloud account, point at a Git repo, and Porter provisions a production-ready Kubernetes cluster inside your account — VPC, load balancers, image registry, the works — then layers a Heroku-like abstraction over it: git-push deploys, preview environments, autoscaling, jobs and cron, managed TLS, logging, and alerting. Applications are Helm releases under the hood, so a team can eject from the abstraction into raw kubectl whenever it outgrows the guardrails. In 2024 Porter added Porter Cloud, a hosted on-ramp that ejects into your own account as you scale.

The pricing is metered on requested app resources, not underlying instance capacity: $13 per vCPU and $6 per GB of RAM per month on Standard, prorated to the minute, with an Enterprise tier (starting around 40 vCPU and 80 GB RAM) offering volume discounts. As TechCrunch noted back in 2021, Porter deliberately does not resell hosting — its fee is pure SaaS. Cloud credits can cover the infrastructure side, which is genuinely useful for funded startups sitting on Activate or Founders Hub credits.

Porter's Series A thesis is that every scaling startup hits a graduation point where Heroku, Render, or Vercel stops fitting, and "all roads eventually lead to a consolidation of services on the hyperscalers." Hundreds of AI companies now run Porter-managed clusters scaling to hundreds of machines, with SOC 2 and HIPAA compliance posture built in. That is a real business solving a real pain. The question is only what the road costs once you're on it.

The second bill, itemized​

Take the typical-team workload above — 4 vCPU and 8 GB RAM of requested app resources — and price the AWS account it lands in. These are standard us-east-1-ish rates, and each line is doing quiet work:

• EKS control plane: $73/mo. AWS charges $0.10 per cluster-hour while your Kubernetes version is in standard support. Let a version lapse past its roughly 14-month window and the cluster slides automatically into extended support at $0.60/hour — $438/mo for the same control plane, no approval step. A dev/staging/prod trio goes from $219 to $1,314 overnight.
• Worker nodes: ~$140/mo. Fitting 4 vCPU and 8 GB of app requests plus kubelet, CNI, and agent overhead realistically means two m6i.large nodes (2 vCPU / 8 GB each at about $0.096/hr). Note the structural mismatch: Porter meters what your apps request, AWS meters the capacity you reserve, and you pay for the slack between them.
• EBS volumes: ~$10/mo. Two 50 GB gp3 root volumes. Small, but it never goes away.
• Load balancer: ~$22/mo. An ALB at $0.0225/hr plus LCU charges for a modest-traffic service.
• NAT gateway: ~$40/mo. $0.045/hr plus $0.045/GB of data processing. Private subnets are best practice; the gateway is the toll.
• Egress: ~$18/mo. The first 100 GB is free, then $0.09/GB. A modest 300 GB/mo of outbound transfer adds eighteen dollars — and this is the line that scales with your success.

AWS subtotal: roughly $303/mo. Add Porter's $100 meter and the all-in number lands around $400/mo for a workload a single developer could hold in their head.

To be fair to Porter, its pricing page anchors against AWS App Runner, where "every additional 2 vCPU and 4GB RAM is $112/mo," and claims the Porter-plus-compute total matches or beats ECS Fargate and Cloud Run equivalents. That comparison is probably right — BYOC does undercut managed-serverless premiums. But notice what it concedes: the benchmark is other meters, never the absence of one.

The owned-machine side, same workload​

Now price the same 4 vCPU / 8 GB workload on owned bare metal. A Hetzner AX42 — 8 cores / 16 threads of Ryzen, 64 GB DDR5, two 512 GB NVMe drives — rents for roughly $55/mo, and that single box holds our example workload about eight times over. Traffic? 20 TB per server included, with overage at about $1/TB — two orders of magnitude cheaper than the $0.09/GB meter. There is no control-plane fee, no NAT toll, no per-GB anxiety when a launch day spikes.

One data point proves nothing, so here is the sensitivity across three workload sizes. The Porter column uses Standard metered rates; the AWS column scales nodes and networking honestly; the Hetzner column stays on current AX-line pricing:

Two patterns survive the sweep. First, the gap is structural, not a misconfiguration: at every size the cloud-account floor (control plane, load balancer, NAT, minimum viable nodes) plus the PaaS meter exceeds the fixed hardware price several times over. Second, the small end is where BYOC hurts most — a side project pays $73/mo for an EKS control plane before serving a single request, while the same fleet model runs it on a $10 cloud VM or a slice of a box that is already paid for.

The honest caveats run both ways. Startup credits can zero out the AWS column for a year or two — but credits expire, and architectures chosen under credits have a habit of outliving them. Enterprise volume discounts bend the Porter curve at 40+ vCPU. And nobody should pretend a bare-metal fleet administers itself — but before the ops question, there is a deeper one: what does "yours" even mean when the meter still belongs to someone else?

Two shapes of sovereignty​

"Runs in your account" is genuinely worth something. Your data stays inside your cloud boundary under your IAM policies, your compliance paperwork inherits the hyperscaler's certifications, your credits apply, and your managed-database and queue services sit one security group away. For teams already committed to AWS with RDS, SQS, and a SOC 2 auditor who knows the drill, BYOC is the cheapest way to keep the Heroku workflow without re-platforming the data layer.

But an account is not ownership — it is a tenancy with a nicer dashboard. The meter underneath is still Amazon's: EKS extended-support pricing, NAT data-processing fees, and egress rates change when AWS says so, and your architecture absorbs it. Provisioning automation needs broad permissions into your account by construction. And the failure modes you must plan for — region degradation, quota limits, a surprise bill from a runaway autoscaler — are the hyperscaler's failure modes, managed through their support queue.

"Runs on machines you own" inverts every one of those. The bill is fixed and forecastable to the euro. There is no per-request tax on success: a launch spike costs the same as a quiet Sunday. Hardware topology is yours to choose — big-RAM boxes for caches, NVMe for build farms — instead of whatever the instance catalog offers this quarter.

The price is that the failure modes are yours too: disks die, uplinks flap, and compliance evidence is gathered by you, not inherited. Anyone selling owned iron without naming that trade is selling, not informing.

The ops-burden objection, answered​

The standard rebuttal to everything above fits in one sentence: sure, the iron is cheap, but who operates it? A Kubernetes cluster on rented machines still needs provisioning, upgrades, node repair, and TLS — and a small team adopting bare metal to save $350/mo can easily spend it back in on-call hours.

That objection was decisive in the single-box era. Tools like Coolify, CapRover, and Dokploy made one server feel like a PaaS, but they solve "manage the box you already have" and stop there: no fleet-wide provisioning, no declarative machine lifecycle, no story for the morning you need a second machine. Outgrowing them means re-platforming — which is exactly the graduation trauma Porter monetizes on the cloud side.

Cluster API is what breaks the dilemma. Machine lifecycle becomes declarative reconciliation — declare the desired fleet, let controllers converge the metal — so adding the ninth node costs the same operational effort as adding the second: near zero. The national-rail-scale CAPI fleets profiled by CNCF run this loop across hundreds of clusters; a Hetzner fleet of three boxes runs the same controllers with far lower stakes. When node provisioning is a reconciled API rather than a ticket queue, "who operates it" stops being a headcount question and the fixed hardware bill becomes pure savings.

The bill is the architecture​

Porter is a good product with an honest pricing page — rare enough to praise. Its $20M bet is that the hyperscaler meter is inevitable and the winning move is the best possible PaaS on top of it. For credit-rich startups, compliance-inherited enterprises, and teams whose data already lives in RDS, that bet pays.

But "your cloud account" was never the opposite of metered computing. It is metered computing with your logo on the invoice — control-plane fees, NAT tolls, and egress taxes, plus the PaaS margin for making it pleasant. Owning the fleet replaces all of that with one fixed hardware bill and a reconciliation loop. Before your next deploy, add up every line of both columns for your actual workload. The meter you don't have is the cheapest one you'll ever run.

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