Dora NodaA service that needs 3 GB of RAM and half a CPU is a small but revealing pricing problem. On a tiered PaaS, it can force a choice between too little memory and buying CPU the process will never use. On a Kubernetes-backed BYOC PaaS, it can be expressed as the request it actually is: 0.5 vCPU and 3 GB.
That is the real appeal of Porter's model. Its published management price is $13 per vCPU-month plus $6 per GB-RAM-month, while the cloud resources remain in the customer's AWS, Google Cloud, or Azure account. The catch is equally important: a precise request does not make the Kubernetes cluster, network, and control-plane costs disappear. It changes which bill is granular, not whether infrastructure has a floor.
The ratio tax, shown before the sales pitch
Here is the useful comparison. The Porter figures below are directly calculated from its public rates. The $201 AWS figure is Porter's own current estimate for its default whole cluster, not a per-app charge or a portable AWS quote. The Render entries are the published monthly rates for long-running web-service plans; its current plan table supplies the resource boundaries. An owned-fleet allocation is intentionally illustrative: it is the share of a fixed $201/month capacity pool assigned to each workload, not a vendor price.
| Always-on workload | Needed ratio | Porter management fee / month | Porter cash view at 1 / 10 / 40 identical apps* | Render plan that can fit it | Render per-service monthly rate | Illustrative owned-fleet allocation / app† |
|---|---|---|---|---|---|---|
| RAM-heavy API | 0.5 vCPU, 3 GB | $24.50 | $225.50 / $446 / $1,181 | 2c-4g; a 1c-2g Standard cannot fit 3 GB | $80 | $20.10 / $2.01 / $0.50 |
| CPU-heavy worker | 2 vCPU, 1 GB | $32.00 | $233 / $521 / $1,481 | 2c-4g Pro; it has 4 GB, so 3 GB is unused | $80 | $20.10 / $2.01 / $0.50 |
| Tiny internal service | 0.1 vCPU, 0.1 GB | $1.90 | $202.90 / $220 / $277 | Starter, 0.5c-512mb; it has 5× CPU and 5× RAM | $7 | $20.10 / $2.01 / $0.50 |
* Porter cash view = its $201 AWS default-cluster estimate plus the displayed management fee multiplied by the number of apps. It is a floor illustration, not a capacity model: a real cluster may need extra nodes before forty RAM-heavy APIs fit, and existing spare capacity may mean no immediate cloud increase. Porter separately lists GCP at about $253/month and Azure at about $165/month for their defaults, so substituting those providers changes the starting point. Porter’s cloud-account documentation is the source for those estimates.
† This allocation simply divides a $201/month fixed capacity pool across 10 capacity-equivalent slots, then across the number of active apps. It leaves out backups, egress, support labor, and the possibility that the mix cannot be packed into the pool. It is included to show the opposite shape of the economics: after capacity is bought, the marginal invoice for another correctly packed app is not a new per-app SKU.
The table answers a narrower question than “which platform is cheaper?” and that is deliberate. It isolates the cost of a lopsided resource ratio. Porter charges the first API for the 3 GB it requests; Render's 2c-4g service provides enough RAM, but also supplies four times the CPU requested. Conversely, the tiny service needs a much smaller allocation than either product's long-running service plan exposes.
Render has recently expanded its memory-oriented plans—there are now several RAM choices at 2+ CPU tiers—so its grid is not frozen in the old “double everything” shape. But it remains a plan grid. Its public documentation lists Starter as 0.5 CPU/512 MB, Standard as 1 CPU/2 GB, and Pro as 2 CPU/4 GB; every scaled instance uses the selected plan. Render’s compute-plan reference and its current pricing explainer list the $7 Starter and $25 Standard examples. The $80 Pro figure is the current listed long-running rate; pricing should be rechecked before buying.
The sensitivity matters more than the one-app headline. At one small app, a BYOC cluster's baseline dominates and the flat hosted tier is usually the simpler bill. At ten or forty services with varied request shapes, granular requests and Kubernetes bin-packing can use an already-running worker pool more closely. Neither conclusion follows from a single hand-picked service.
What Porter's precision actually buys—and what it does not
Porter says its resource configuration goes down to 1 MB RAM and 0.01 vCPU in older comparison material. That is a useful statement about the configuration and scheduling model, but it should not be turned into a current checkout promise. The live pricing calculator presently displays inputs beginning at 0.1 vCPU and 0.1 GB. The defensible conclusion is: Porter supports much more granular app requests than a fixed compute-plan menu; the exact minimum a new customer can select should be confirmed in the dashboard or with Porter.
The mechanism underneath is ordinary Kubernetes, not magic billing. An app declares CPU and memory requests; the scheduler places it on a node with enough allocatable capacity; autoscaling can add or remove application capacity. A 0.5-vCPU/3-GB service is valuable because the request preserves its ratio. The remaining CPU can be used by another workload instead of being silently stranded inside a larger instance tier.
There are three qualifications worth keeping in the same sentence as “pay for what you use.”
- Porter bills for requested app resources, not for a perfectly measured share of a virtual machine. An oversized request remains an expensive request even when the process is idle.
- The cloud provider bills for the cluster's nodes, control plane, load balancers, storage, and network according to its own rules. Those costs do not necessarily move in the same increments as an application request.
- Packing has physical limits. CPU fragmentation, memory fragmentation, availability headroom, pod disruption budgets, and a requirement to keep more than one replica can leave capacity unused.
Those qualifications do not negate granular billing. They say where it is strongest: a team with enough workloads to form a pool, meaningful variation in CPU-to-RAM ratios, and the ability to right-size requests continuously. Porter's own quickstart shows the intended developer experience—source or Docker deployment, a porter.yaml service definition, and CPU/RAM settings—while the platform handles the cluster layer. The quickstart is also explicit that Porter provisions in the connected cloud account.
BYOC's fixed cost is a feature of the ownership model
“Bring your own cloud” is often read as “bring only your cloud credits.” It is more substantial than that. The account holder owns the cloud resources and pays the cloud vendor directly; Porter charges for managing the infrastructure and developer experience above them. Porter's pricing page is unusually direct on both points: cloud-provider cost is excluded from its quoted resource price, and an account that stops paying Porter keeps its servers and Kubernetes cluster but takes on their operation. Read the pricing FAQ.
That creates a real initial floor. Porter's documented default AWS cluster includes separate system, monitoring, and application node groups; the cloud-account docs estimate the resulting baseline at around $201/month, before a workload-specific capacity expansion. A product team with one tiny service is not buying $1.90/month of complete production infrastructure. It is buying a small management allocation plus a production-shaped cloud substrate.
This is not a defect. For the right organization, it is the point:
- The infrastructure, data, billing account, IAM policies, and cloud credits remain in the customer's boundary.
- The team can select AWS, GCP, or Azure and keep direct access to the underlying resources.
- A compliance program that requires a dedicated account/VPC boundary gets an architecture it can inspect rather than a shared-hosting abstraction.
It also means the customer must grant meaningful privileges. Porter's setup requires an account with admin or owner permissions to create clusters, networking components, and IAM roles; on AWS, it uses a porter-manager IAM role. Deleting that role prevents further management. The setup guide spells out both the permission and revocation path. BYOC transfers control and exit leverage to the customer; it does not transfer away the responsibility for the cloud account.
These are three different ownership boundaries, not three prices for one product
Comparisons get misleading when they place a hosted PaaS, a BYOC control plane, and a self-hosted fleet in one price column. They sell different boundaries.
| Question | Hosted Render service | Porter BYOC PaaS | End-to-end owned-machine platform |
|---|---|---|---|
| Where do app machines and data-plane resources run? | Render's infrastructure | Customer AWS/GCP/Azure account | Hardware or hosting account chosen and operated by the team |
| Who receives the infrastructure invoice? | Render, through workspace and service charges | The customer receives the cloud invoice; Porter invoices its management layer | The team pays the hardware/hosting provider directly |
| Who operates Kubernetes? | The hosted service abstracts it | Porter manages the provisioned cluster while access remains granted | The team or its chosen operator manages it |
| What remains after the platform relationship ends? | The service must be migrated from the hosted platform | Kubernetes and cloud resources remain, but the customer operates them | The control plane and machines are already in the team's boundary |
That is why a flat monthly plan and BYOC resource billing cannot be judged solely from the rate card. A hosted plan prices a complete operating boundary. BYOC prices a management layer plus a cloud account the customer already owns. An end-to-end self-hosted platform replaces the rented management layer with software the team operates, but makes fleet operation part of the job.
Porter supports SOC 2 and HIPAA-oriented infrastructure controls on AWS, with integrations for compliance automation; its documentation correctly frames that as infrastructure support, not a guarantee that a customer's application is compliant. Porter’s compliance page says the feature is currently AWS-only. That caveat reinforces the boundary: account ownership and controls are powerful, but workload logging, data handling, and the remaining compliance obligations still belong to the team.
Pick the cost question before picking the price model
Start with four questions:
- Is the main problem a lopsided CPU/RAM ratio, or simply a very small number of services? Granular requests address the first; a hosted plan often minimizes the initial burden of the second.
- How many independently sized workloads will share capacity, and how much headroom does production require? Use a 1/10/40-style sweep, not a single service, to test the answer.
- Must the workload live inside a particular cloud account, VPC, credit program, or compliance boundary? If so, the ownership model can matter more than a few dollars of resource rounding.
- If the management layer is removed, who patches, upgrades, monitors, and responds to the cluster? The right exit plan is an operating plan, not just an export button.
Porter's granular model makes the ratio tax visible and gives a BYOC team a way to reduce it. The price of that control is a persistent cloud floor and an explicit cloud-account responsibility. A flat hosted plan makes the starting experience simpler and bundles more of the operating boundary; an owned fleet changes the marginal-cost curve again, but only after a team accepts responsibility for that fleet.
Bex.co is an open-source, AI-native Render alternative for teams that want to push a Git repo to a running HTTPS service on machines they operate. Its useful comparison point here is ownership boundary: the platform control plane and fleet are in the team's hands, not a separate BYOC management subscription. Explore the project on GitHub.
