Heroku Private Spaces Security Features: The Complete List (and 6 Controls You Can't Add)

Key takeaways

• Heroku Private Spaces ship eight named security features: a network-isolated runtime pinned to one region, stable outbound IPs, Trusted IP Ranges (an inbound CIDR allow-list), Private Space VPN (IPSec), Private Space Peering with an AWS VPC you own, AWS PrivateLink for data services, Internal Routing for apps that must never be publicly reachable, and Private (dedicated) Dynos (Heroku Dev Center).
• Heroku Shield Private Spaces are the regulated tier on top of that: Shield dynos with an encrypted ephemeral filesystem, Shield Postgres, Shield Kafka, and a Shield Key-Value Store, stricter session and connection rules, and a space-wide log drain (Shield Private Space). Shield is the tier Heroku scopes for PHI under a HIPAA agreement and for PCI (Heroku compliance).
• A Private Space is isolation inside Salesforce-owned AWS infrastructure, not inside your AWS account. You cannot attach your own KMS keys, GuardDuty, infra-layer CloudTrail, service control policies, security groups, NACLs, or VPC flow logs. You get the controls Heroku chose to expose and no more.
• Private Spaces are available to verified Heroku Teams and Heroku Enterprise, and the space carries no public standalone price. You pay per Private or Shield dyno plus data add-ons, starting at $125/month for a Private-S dyno. None of that spend is eligible for AWS Savings Plans, GCP committed use discounts, or Azure reservations, because the cloud bill is not in your name.
• Heroku's Fir generation went GA on 14 April 2025 and re-implements the runtime on Kubernetes and OCI images (Fir GA changelog), so Private Spaces feature availability differs between Cedar and Fir. Confirm your space's generation before you answer a security questionnaire.
• If you want Private Spaces-style isolation with controls your auditors can inspect in an account you own, a bring-your-own-cloud internal developer platform such as Qovery deploys into your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster while keeping the git-push developer experience.

Most people who search for this are halfway through a security review or a vendor questionnaire, and the Heroku docs tell you what a Private Space includes but never what it leaves out. I have sat on both sides of that questionnaire, so this article does both: the complete, named feature list first, then the six controls a Private Space structurally cannot give you. Here is the list.

What security features do Heroku Private Spaces include?

A Heroku Private Space is a dedicated runtime that runs your dynos and add-ons inside an isolated network in one chosen region, available to verified Heroku Teams and Heroku Enterprise (Heroku Dev Center). A Heroku Private Space includes eight security features: network isolation, stable outbound IPs, Trusted IP Ranges, Private Space VPN, Private Space Peering, AWS PrivateLink for data services, Internal Routing, and Private (dedicated) Dynos, with Heroku Shield Private Spaces adding a regulated-workload tier on top.

Here is each feature, named the way Heroku names it, so you can lift any single line into a questionnaire:

• Network isolation. A Private Space runs in its own isolated network so your dynos and private add-ons do not share a network with other tenants (Private Spaces).
• Stable outbound IPs. All outbound traffic from apps in a Private Space leaves from "a small, stable list of IP addresses dedicated to the space" (Private Spaces), which is what lets a partner, bank, or third-party API allow-list you.
• Trusted IP Ranges. An inbound allow-list of CIDR blocks (for example 192.0.2.0/24) that controls which source addresses can reach routable apps in the space (Trusted IP Ranges).
• Private Space VPN. An IPSec VPN connection from the space to a network you own, using IKEv1 or IKEv2 with a pre-shared key (Private Space VPN).
• Private Space Peering. A private VPC peering connection between the space and an AWS VPC you control, so traffic never crosses the public internet (Private Space Peering).
• AWS PrivateLink. Private connectivity from your AWS VPC to Heroku data services (Heroku Postgres, the Heroku Key-Value Store, and Apache Kafka on Heroku) without traversing the public internet (PrivateLink changelog).
• Internal Routing. Apps you mark as internally routed "can't receive external web traffic to their web process type" and are reachable only from other apps in the space or from VPC-peered and VPN-connected networks (Private Spaces).
• Private (dedicated) Dynos. Your web and worker processes run on dedicated Private dynos (Private-S through Private-2XL) rather than shared multi-tenant compute (Dyno types).

Two supporting features round it out. Private Space Logging ships all app and system logs from the space to a single log drain you choose, and it has to be set when the space is created (Shield Private Space). DNS Service Discovery lets apps in a Cedar space find each other by name (Private Spaces).

One caveat belongs right next to the list. Heroku now runs two generations, Cedar (the legacy platform) and Fir (GA on 14 April 2025, built on Kubernetes and OCI images), and several networking features are Cedar-only or still being brought to Fir (Heroku generations). Confirm which generation your space is before you assert any of these features in an audit. The matrix below carries a dedicated Cedar-vs-Fir column for exactly that reason.

How does network isolation actually work inside a Heroku Private Space?

A Heroku Private Space runs in its own isolated network pinned to a single region, inbound public traffic reaches your routable apps only after passing the Trusted IP Ranges allow-list, and all outbound traffic leaves from a small fixed set of IP addresses you can publish to partners (Private Spaces). That single-region pinning is the fact your data-residency questionnaire cares about: a space created in frankfurt or dublin keeps its dynos and private data services in that region, and Heroku publishes ten Private Space regions in total (dublin, frankfurt, london, montreal, mumbai, oregon, singapore, sydney, tokyo, virginia) (Heroku regions).

Trusted IP Ranges are the one inbound network control you configure yourself. You express the allow-list in CIDR notation, and a newly created space starts with a default range of 0.0.0.0/0, which admits the entire internet until you tighten it (Trusted IP Ranges). That default catches teams out on their first audit, so change it early. A Cedar space accepts up to 20 ranges; a Fir space adds an ::/0 IPv6 default and raises the limit to 100 (Private Space limits). The ranges apply to web processes on Cedar and to all routable processes on Fir.

Outbound traffic is the mirror image. On the multi-tenant Common Runtime your egress addresses are not fixed, so you cannot hand a stable IP to a partner. Inside a Private Space, egress comes from "a small, stable list of IP addresses dedicated to the space" (Private Spaces). Heroku does not publish an exact count of those NAT addresses in its docs, so treat the docs as the source of truth and do not quote a number you cannot cite.

For reaching networks you own, a Private Space gives you two documented paths:

• Private Space VPN. An IPSec tunnel to your VPN gateway using IKEv1 or IKEv2 with pre-shared-key authentication. Heroku supports one VPN connection per space, provisioned with two redundant tunnels (Private Space VPN).
• Private Space Peering. A VPC peering connection to an AWS VPC you control. The space is created with one of the default CIDR ranges 10.0.0.0/16, 10.1.0.0/16, or 172.17.0.0/16, your VPC must use a non-overlapping RFC1918 block, and you can peer up to five AWS VPCs per space (Private Space Peering).

AWS PrivateLink covers the data tier: your VPC can connect privately to Heroku Postgres, the Heroku Key-Value Store, and Apache Kafka on Heroku running in the space, in the same region as the database, without crossing the public internet (PrivateLink changelog). And Internal Routing handles service-to-service traffic: an internally routed app "can't receive external web traffic to their web process type" and answers only to other apps in the space or to peered and VPN-connected networks (Private Spaces).

Now the limits, stated plainly because they matter more than the features when you are writing a control narrative. Inside a Private Space you do not get security groups, you do not get network ACLs, you do not get VPC flow logs, you do not get a customer-configurable WAF or any layer-7 rules, you cannot filter egress by destination, and you cannot run an IDS or IPS of your own. The only inbound network knob you own is the CIDR allow-list.

What do Heroku Shield Private Spaces add, and when do you actually need one?

Heroku Shield Private Spaces are Heroku's regulated-workload tier, and a Shield space adds Shield dynos with an encrypted ephemeral filesystem, Shield data services (Shield Postgres, the Shield Key-Value Store, and Apache Kafka on Shield), stricter session and connection rules, and a space-wide log drain (Shield Private Space). Heroku scopes Shield as the tier for handling PHI under a Business Associate agreement and for PCI-covered applications (Heroku compliance).

The Shield restrictions are the point, not a side effect. In a Shield space, all input typed into an interactive heroku run session is logged to the space log stream, interactive sessions require an SSH key, Heroku Exec (SSH tunneling) is not supported, external connections to Shield Postgres and the Shield Key-Value Store are disabled, and Postgres backup downloads are turned off (Shield Private Space). Those are the guardrails an auditor wants to see, and they trade convenience for a cleaner control story.

On the data services, the pattern is consistent: Shield Postgres and Kafka on Shield allow classes of regulated data that the plain private plans do not, and the Shield Key-Value Store prevents external connections and requires encrypted clients (Shield Private Space). Space-wide logging is how evidence leaves the platform: a Shield space is created with a single log drain URL for every app in the space, and that drain cannot be added after creation, so you point it at your SIEM on day one.

The compliance posture behind Shield sits with Salesforce. Heroku states that "Salesforce has an Attestation of Compliance as a PCI Level 1 Service Provider covering Heroku Shield Services offered as part of Heroku Enterprise," offers a Business Associate Addendum for HIPAA through its sales team, and inherits SOC 2 Type 2 and ISO 27001 coverage through Salesforce (Heroku compliance), with the underlying reports on the Salesforce Trust site. That BAA is not optional paperwork: the HIPAA Rules "generally require that covered entities and business associates enter into contracts with their business associates" that touch PHI (HHS), and healthcare breaches are not rare (more than 700 breaches of 500 or more records were reported to HHS in 2024, the third straight year above that mark, per HIPAA Journal's analysis of the OCR breach portal).

Shield does not move the shared-responsibility line, it just relocates it. AWS frames this as security "of" the cloud versus security "in" the cloud (AWS); with Shield, Salesforce secures the platform, and you still own app-level security, secrets rotation, dependency patching, and access reviews.

Here is the fair part, and I mean it. For a five-person team with a HIPAA deadline next quarter and nobody who wants to own a Kubernetes cluster, a Shield Private Space is a genuinely good answer. You get a signable BAA, single-tenant isolation, encrypted data services, and off-platform logging without hiring a platform engineer. On cost, be clear-eyed rather than precise: Heroku does not publish a standalone per-space price, and Shield dynos and Shield data services list materially above their standard equivalents on top of your Enterprise contract, so check the current numbers on the Heroku pricing page rather than trusting a figure from a blog.

What don't Heroku Private Spaces give you? (6 controls you cannot add)

Because a Heroku Private Space is isolation inside Salesforce-owned AWS infrastructure rather than inside your own cloud account, six controls are structurally unavailable at any price point: cloud-account access, customer-managed encryption keys, layer-7 controls, broad region coverage, committed-use discounts, and a guaranteed add-on network perimeter. None of these is a pricing tier you can buy up into. They follow from where the account boundary sits.

1. No access to the underlying cloud account. You cannot turn on GuardDuty, read infra-layer CloudTrail, apply service control policies, or run AWS Config rules against the account your dynos live in, because that account belongs to Salesforce. CloudTrail records "actions taken by a user, role, or an AWS service" as events (AWS CloudTrail), and a Private Space gives your auditors no way to inspect that trail directly.

2. No customer-managed encryption keys. Shield encrypts data, but the keys are Heroku's, not yours. An AWS KMS customer-managed key is one "you create, own, and manage," with a key policy "exclusively controlled by the customer" (AWS KMS). You cannot hold that key, rotate it on your own schedule, or revoke it inside a Private Space, which is a hard blocker anywhere bring-your-own-key or hold-your-own-key is mandated.

3. No layer-7 controls. Trusted IP Ranges filter by source CIDR and nothing more, so a WAF, bot management, and rate limiting all have to live upstream of the space, outside your isolation boundary. A source-IP allow-list does nothing against most of the OWASP Top 10:2025: an allow-listed client can still send an injection payload (A05) or exploit broken access control (A01).

4. A short region list. Heroku publishes ten Private Space regions (Heroku regions). AWS publishes 39 Regions across 124 Availability Zones (AWS global infrastructure) and Google Cloud publishes 43 regions (Google Cloud locations). If your residency requirement lands outside Heroku's ten, there is no configuration that fixes it.

5. No committed-use economics. Because the cloud invoice is in Salesforce's name, you cannot apply AWS EC2 Instance Savings Plans (up to 72%, or up to 66% on the flexible Compute Savings Plans, per AWS), Google Cloud committed use discounts (up to 70% on some machine types, per Google Cloud), or Azure reservations (up to 72%, per Microsoft). At scale that discount gap is often the single largest line-item difference.

6. Add-on perimeter gaps. Third-party add-ons from the Heroku Elements marketplace can sit outside the space's network boundary unless they are reached over PrivateLink, which is a recurring finding when a regulated team maps its data flows. Anything that is not PrivateLink-backed is another vendor to diligence and another egress path to document.

There is a seventh thing to put on your risk register rather than your control list: generation parity. Through the Cedar-to-Fir transition, features like VPN, VPC peering, and Internal Routing are Cedar-only or still being ported (Heroku generations), so "does my space support this control" now depends on which generation it runs. I go deeper on the pricing and networking mechanics in our companion piece, Heroku Private Spaces vs AWS; this article stays on the security feature set itself.

How do Heroku Private Spaces compare to AWS, GCP, Azure, or your own Kubernetes cluster?

Heroku Private Spaces buy near-zero-effort isolation behind a fixed monthly floor, while building the equivalent in your own cloud account buys ownership of encryption keys, network controls, audit logs, and committed-use discounts at the cost of platform engineering, and the deciding factor is whether your auditors need to inspect controls inside an account you own. If the answer is no, a Private Space is hard to beat on time-to-value. If it is yes, no Heroku tier reaches it.

Be fair about where Heroku wins outright: time-to-compliance, zero operational burden, and a BAA you can sign this week without provisioning a single subnet. Where your own AWS, GCP, Azure, or Kubernetes account wins is the list of controls a Private Space cannot expose: your own KMS keys, CloudTrail in your account, security groups and NACLs, private subnets, a WAF and IDS you run, VPC flow logs that "capture information about the IP traffic going to and from network interfaces" (AWS), multiple regions, and the committed-use discounts above.

The PaaS peers land in between, and the honest read on each is:

• Render offers private services that are "not reachable via the public internet" and private networking between services, and publishes SOC 2 Type 2 and ISO 27001, with HIPAA-enabled workspaces and a signable BAA on its Scale and Enterprise plans (Render trust, Render HIPAA). Like Heroku, Render runs in its own account.
• Northflank deploys into your own cloud in bring-your-own-cloud mode, provisioning and managing Kubernetes in "your own AWS, GCP, Azure, Oracle, or CoreWeave accounts," and states it is SOC 2 Type 2 and HIPAA compliant (Northflank BYOC).
• Porter "runs in your own AWS, GCP, or Azure account," standing up a cluster there, and markets SOC 2 and HIPAA in your account (Porter docs).

That middle ground has a name: an internal developer platform that runs on infrastructure you already own. The four-way table lays out the tradeoff on the dimensions a security review actually scores.

What is the best alternative if you want Private Spaces isolation inside your own cloud account?

Run the developer experience on top of infrastructure you own: a bring-your-own-cloud internal developer platform deploys your applications into your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster, so the network controls, encryption keys, audit logs, and the cloud bill all stay in your name while developers keep pushing to git. Qovery is one such platform. The model is simple to state: the Qovery control plane orchestrates deployments, and your workloads and data never leave your cloud account.

The reason this matters for a security review is that every Private Spaces feature has an in-account equivalent you own outright:

• Trusted IP Ranges become security groups plus a WAF you configure.
• Shield encryption at rest becomes your own AWS KMS, Google Cloud KMS, or Azure Key Vault keys, with a key policy "exclusively controlled by the customer" (AWS KMS).
• The Heroku audit trail becomes your own CloudTrail plus VPC flow logs.
• Internal Routing becomes private subnets and internal load balancers.
• AWS PrivateLink for data services becomes your own AWS PrivateLink, Google Cloud Private Service Connect, or Azure Private Link endpoints.
• Private Space Peering becomes native VPC peering or an AWS Transit Gateway hub.

What Qovery gives your developers on top of that account is the part that makes it feel like Heroku: git-push deployments, a preview environment per pull request, automatic environment stop for non-production, managed cluster upgrades, per-environment role-based access control, and databases backed by your cloud provider's managed services. It runs on infrastructure teams already have; Kubernetes production use reached 82% of organizations in 2025 (CNCF), so "run it on your own cluster" is no longer an exotic ask.

I will state the boundary honestly, because it is the question a compliance lead will ask next: Qovery does not issue a BAA and does not hand you a PCI attestation. Your cloud provider's compliance program plus your own controls and evidence do that work. Qovery orchestrates the deployment; the certifications live with the account owner, which is you.

So the fit guidance is simple. Stay on a Shield Private Space if you have no cloud footprint and a compliance deadline next quarter. Move to bring-your-own-cloud if you already run an AWS, GCP, Azure, or Scaleway organization, have a security team that wants its own keys and logs, or hold committed-use discounts you cannot apply to a Heroku invoice.

How should you decide between a standard Private Space, a Shield Space, and your own cloud account?

Three questions settle it: do your auditors require controls inside an account you own, do you already run a cloud organization with committed-use discounts and security tooling, and does anyone on your team run Kubernetes today. Two or more yeses point to bring-your-own-cloud in your own account; zero yeses point to a Shield Private Space. Each line below stands on its own as a decision rule:

• If an auditor must inspect your KMS keys and raw logs in your account, a Private Space cannot pass, so choose your own account.
• If your data-residency requirement sits outside Heroku's ten Private Space regions, choose your own account or a BYOC platform.
• If you need multi-region active-active, choose your own account.
• If a contract mandates customer-managed keys or a WAF and IDS, choose your own account.
• If your monthly spend is large enough that Savings Plans, CUDs, or reservations change the maths, choose your own account.
• If you have no cloud footprint, no platform engineer, and a near-term HIPAA or PCI deadline, choose a Shield Private Space.

When you do decide to leave, sequence the migration so the surprises come early: inventory your add-ons first (this is where teams get caught, because a marketplace add-on outside the perimeter is quiet until an auditor asks), then the data services, then networking and egress IPs, then the apps, then the DNS cutover. The inventory and networking phases usually run in weeks rather than days, so plan the calendar around them. The companion Heroku Private Spaces vs AWS article linked above has the worked pricing and networking numbers behind that plan.

Frequently asked questions

What security features do Heroku Private Spaces include?

Heroku Private Spaces include eight named security features: network isolation, stable outbound IPs, Trusted IP Ranges, Private Space VPN, Private Space Peering, AWS PrivateLink for data services, Internal Routing, and Private (dedicated) Dynos (Heroku Dev Center). Heroku Shield Private Spaces add a regulated-workload tier on top with Shield dynos, Shield data services, and space-wide logging (Shield Private Space).

What is the difference between a Heroku Private Space and a Heroku Shield Private Space?

A standard Heroku Private Space gives you the isolated network, Trusted IPs, stable outbound IPs, VPN, peering, and dedicated dynos, while a Heroku Shield Private Space adds regulated-workload controls: Shield dynos with an encrypted ephemeral filesystem, Shield data services, logged interactive sessions, disabled external database connections, and a space-wide log drain (Shield Private Space). Heroku scopes Shield, not the standard space, for PHI and PCI workloads (Heroku compliance).

Are Heroku Private Spaces HIPAA and PCI DSS compliant, and does Heroku sign a BAA?

HIPAA and PCI DSS coverage are features of Heroku Shield, and Salesforce holds "an Attestation of Compliance as a PCI Level 1 Service Provider covering Heroku Shield Services" and offers a Business Associate Addendum for HIPAA through its sales team (Heroku compliance). The HIPAA Rules require that agreement with any vendor that touches PHI (HHS), so confirm your workload is on Shield, not a standard space.

Do Heroku Private Spaces run in my own AWS account, and can I use my own KMS keys?

No, a Heroku Private Space runs inside Salesforce-owned AWS infrastructure, not your AWS account, so you cannot attach your own KMS keys, security groups, or CloudTrail. An AWS KMS customer-managed key is one you "create, own, and manage" with a policy "exclusively controlled by the customer" (AWS KMS), and that level of key custody is only available when the account is yours, such as in a bring-your-own-cloud setup.

How do Trusted IPs work in a Heroku Private Space, and what is the default inbound rule?

Trusted IP Ranges are an inbound allow-list of source CIDR blocks that control which addresses can reach routable apps in the space, and a newly created space defaults to 0.0.0.0/0, which admits the entire internet until you restrict it (Trusted IP Ranges). A Cedar space accepts up to 20 ranges; a Fir space adds an ::/0 IPv6 default and allows up to 100 (Private Space limits).

How much does a Heroku Private Space cost, and is it Heroku Enterprise only?

Private Spaces are available to verified Heroku Teams and Heroku Enterprise, and the space itself carries no published standalone price; you pay per Private or Shield dyno plus data add-ons, starting at $125/month for a Private-S dyno (Heroku pricing). Shield dynos and Shield data services list above their standard equivalents, so price the specific dyno and data tiers you need rather than assuming a flat space fee.

What are the best alternatives to Heroku Private Spaces for isolated, compliance-ready deployments?

The strongest alternatives keep the git-push workflow while running in an account you own: Qovery, Northflank, and Porter all deploy into your own cloud account (Northflank BYOC, Porter docs), and Render offers private services with a signable HIPAA BAA in its own account (Render HIPAA). Choose a bring-your-own-cloud platform when your auditors need keys, logs, and controls inside your account; choose a Shield Private Space when you want Heroku to own all of that for you.

If you already run a cloud organization, the controls your auditors keep asking for (your own keys, your own logs, your own network rules, your own discounts) live in your account, not in a Private Space. Qovery gives your developers the Heroku-style git-push experience on top of that account, whether it is AWS, GCP, Azure, Scaleway, or a Kubernetes cluster you already operate. You can try it free and have something deploying in under ten minutes.