A “private compute service” is dedicated infrastructure that lives in one tenant’s hands. The phrase covers two very different products, and the SERP hides the gap: enterprise colocation brochures (BT, Intercity, similar) describe a contracted rack in a shared data centre run by someone else’s operations team, while modern developer platforms describe an isolated app runtime that behaves like a private instance inside a multi-tenant cloud. The first is a lease agreement with a hardware vendor. The second is a network namespace and a process group with a billing boundary. Picking the wrong one is how teams end up paying for colocation they never needed, or trying to host a real-time app in a “private compute” sandbox that does not actually isolate anything.
The shorter version: if your project is a single app, a service, a worker, or a small set of workloads that all need to talk to each other and not to the rest of the internet, the developer-platform interpretation is the one that applies. If you are a bank, hospital, or government department evaluating hardware contracts with a facilities team, the colocation interpretation is the one that applies — and that is a procurement story, not a developer story.
Table of contents
- The two products that share the name
- What “private” actually means in each version
- When the enterprise brochure version is the right answer
- When the developer platform version is the right answer
- What private compute gives you on RunxBuild
- FAQ
- Closing thought
The two products that share the name
A search for “private compute service” returns mostly enterprise IT procurement documents. BT’s Private Compute service is a contracted facility where you rent rack space, power, cooling, and hardware managed by BT’s data centre team, in a building you do not own. Intercity, Sungard, and similar vendors sell the same idea under their own brand. The buyer is an IT director with a multi-million budget, a hardware refresh cycle, and a compliance checklist that does not bend for engineering convenience.
The developer-platform interpretation is different and newer. A platform like RunxBuild, Render, Railway, Fly, or Vercel exposes a “private” instance per app or per workspace: the workload runs on infrastructure that no other tenant can reach, the network is isolated behind private addressing, the ingress is locked to your team’s identity, and the bill is structured around the resources that one workload actually consumes. The buyer is a developer, a team lead, or a founder who needs isolation for security, compliance, or operational reasons but does not have a facilities team or a hardware refresh contract.
These two products overlap in one specific place: both promise that a workload runs on hardware where no other tenant can eavesdrop on its memory, its network traffic, or its disk. The mechanisms are completely different. The buyer is different. The price tag is off by two orders of magnitude.
What “private” actually means in each version
| Capability | Enterprise colocation | Developer platform private compute |
|---|---|---|
| Physical rack | Dedicated rack in vendor’s DC | Shared rack, isolated namespace |
| Network isolation | VLAN or VRF across vendor’s fabric | Per-app VPC subnet, no cross-tenant traffic |
| Disk isolation | LUNs on dedicated storage | Encrypted volumes scoped to one app |
| Identity | LDAP, RADIUS, vendor IAM | Platform IAM + your own SSO |
| Compliance | SOC 2, ISO 27001, vendor certifications | Inherits platform’s compliance posture |
| Billing | Multi-year contract, monthly fee | Per-usage, like everything else on the platform |
| Buyer | IT procurement, CFO sign-off | Dev team or founder credit card |
The column on the right is what the rest of this post is about. If the column on the left matches what your team is evaluating, this is the wrong post for you — and that is fine, the brochures for those services are very specific about why the buy is worth it.
When the enterprise brochure version is the right answer
You are evaluating dedicated infrastructure in someone else’s data centre when the workload has constraints a multi-tenant platform cannot meet. The most common reasons are:
- Sovereign data residency that the legal team has signed off on, where the data and the compute must stay inside the country’s borders.
- A regulated workload — PCI-DSS at the highest level, government IL5/IL6, financial-market infrastructure — that requires audit trails and certifications a developer platform does not currently hold.
- A hardware-specific dependency: bare-metal GPUs that cannot be virtualised, a custom accelerator, a network appliance that has to live in a physical rack.
- A long-running capital expenditure plan where the finance team prefers to amortise the rack over five years instead of carrying it as a monthly operating cost.
Those are real reasons. None of them are fixable by switching the developer-platform column on in this post. The honest answer for those teams is to keep talking to the colocation vendors and to keep treating private compute at the developer-platform layer as an entirely different product.
When the developer platform version is the right answer
You want private compute on a developer platform when your workload needs isolation for reasons that have nothing to do with hardware contracts. The reasons we see most often on RunxBuild:
- Per-app VPC: the app and the database sit on a private subnet that no external request can reach directly, but the app can still call the database over the private network. The public ingress is the only attack surface; the database is reachable only from the app.
- Multi-environment isolation: production, staging, and the preview environments for in-flight pull requests all run in separate namespaces with separate IAM. A leaked credential in a preview environment cannot reach the production database, even if the database lives on the same physical hardware.
- Customer data isolation: an app that serves multiple tenants, where the data path for each tenant must not share a network namespace with anyone else. Per-app isolation gives you a hard boundary at the platform layer, not just at the application layer.
- Compliance posture the platform already holds: SOC 2 Type II on the host platform covers your workload’s network isolation, encryption at rest, and access logging, without a dedicated DC audit.
- Team-level blast radius: each team gets its own VPC. A misconfigured firewall rule in one team’s namespace cannot take down another team’s service.
This is the version of private compute that a developer reaches for. It is the one that fits a single working week of configuration rather than a procurement cycle.
What private compute gives you on RunxBuild
On RunxBuild, the private compute features are an opt-in per app or per workspace: an app with private networking enabled gets its own subnet, its own DNS zone, its own set of environment variables, and its own IAM. The database and the app sit in the same private network — the app can connect to the database using the private hostname, and external traffic never reaches the database directly. The fact that several apps can sit side by side in the same account, each in its own private namespace, is the part that maps onto the brochure word “private”.
If you are sizing the cost of running this kind of setup, the hosting calculator is the right place to model it. It pulls in the private network costs, the database size, the egress, and the worker pool together so you can see the line items rather than betting on a flat monthly number. The private network overview covers the three meanings of “private network” in cloud apps — the cloud-VPC version, the VPN-overlay version, and the on-prem version — and which one to pick when. The docs for services and the docs for databases cover the wiring once you have decided the architecture.
FAQ
Is a private compute service the same thing as a virtual private cloud?
No, though they overlap. A virtual private cloud (VPC) is the network-isolation primitive. A private compute service is the broader product that bundles a VPC with the compute that lives inside it, the storage that the compute uses, and the identity that gates access. On a developer platform the two are usually sold together.
Do I need a private compute service for a small app?
For a single static site or a one-endpoint API, probably not. The isolation adds operational overhead (a network rule to write, a private hostname to remember, a budget line to track) for little gain on a workload that has nothing sensitive to protect. The use case starts to make sense when there are at least two services that need to talk to each other and you do not want the database visible to the public internet.
Can I run a private compute service on a free tier?
Most platforms do not expose private networking on the free tier because the isolation primitives cost the platform something real (a VPC, a subnet, a routing entry) and that cost is hard to recover from a zero-dollar plan. The pricing usually shows up as soon as you enable the feature, even if the resource usage itself is tiny.
How is private compute different from running on dedicated hardware?
Dedicated hardware is the colocation model: a physical rack or a physical host assigned to your tenant. Private compute on a developer platform is a software-defined isolation layer on top of shared hardware. The shared-hardware version is cheaper and more flexible; the dedicated-hardware version satisfies audits that the software version cannot.
Will a private compute service make my app faster?
Usually not. The latency between services inside the same private network is similar to the latency between services crossing a public network, sometimes a bit better. The win is security and blast-radius reduction, not performance.
Closing thought
“Private compute” is a procurement word when the buyer is an IT director and an engineering word when the buyer is a developer. The two products share a name because they promise the same outcome — your workload is the only one that can see your workload — and almost nothing else. If you are sizing a single app or service that needs real isolation, the developer-platform version gets you to a private network in the same afternoon. If you are evaluating a multi-year colocation contract for a regulated workload, that is a different conversation entirely and the brochures are more useful than this post. The RunxBuild hosting calculator is the right place to start if the developer version is the one your team is evaluating.