Last updated: March 2026

Heroku Shield can support HIPAA workloads. It cannot make you HIPAA compliant, and under sustaining engineering, the gaps it doesn't close today are unlikely to close at all.

The short answer

Yes, Heroku can support HIPAA workloads, but only through Heroku Shield, only under enterprise contracts, and only if you understand and own the significant compliance responsibilities that Shield does not cover.

HIPAA compliance is not a product certification. No infrastructure provider can make you HIPAA compliant. What providers can do is offer infrastructure controls that support your compliance posture when combined with application-level controls, policy documentation, access management, and ongoing audit evidence generation. Heroku Shield does this for regulated infrastructure. Whether Shield is sufficient depends on your specific compliance posture, your audit requirements, and your growth trajectory.

The question most teams should be asking isn't "is Heroku HIPAA compliant?" It's "does Heroku Shield fit our compliance model for the next two to three years?"

What Heroku Shield includes

Shield is Heroku's enterprise compliance tier, available under enterprise contracts. It includes dedicated infrastructure components designed to support HIPAA-eligible workloads.

Shield dynos and Private Spaces

Shield dynos run on dedicated compute, not the shared infrastructure used by standard Heroku dynos. Private Spaces provide an isolated network environment with private connectivity, dedicated routing, and configurable IP allowlisting.

For HIPAA purposes, the key benefit is workload isolation. PHI runs on compute that is not shared with other Heroku customers. Private Spaces control inbound and outbound networking at the environment level, which supports the network access controls required under HIPAA.

Shield Postgres

Shield Postgres is the HIPAA-eligible database tier. It includes encryption at rest, encryption in transit, and enhanced access controls compared to standard Heroku Postgres. Shield Postgres is required for any database storing PHI under a Shield workload.

Shield Postgres also includes enhanced backups and HA (high availability) configurations, which support HIPAA's data backup and recovery requirements.

Encryption, logging, and keystroke auditing

Shield includes encryption at rest and in transit across compute and database tiers. Enhanced logging is available compared to standard Heroku. Certain Shield configurations include keystroke auditing for SSH access.

These controls matter during audits. They are part of what you point to when demonstrating that access to PHI is logged and traceable.

The BAA (and the contract requirement)

Heroku will sign a Business Associate Agreement with customers under enterprise contracts. This is a legal requirement under HIPAA for any infrastructure provider that processes, stores, or transmits PHI on your behalf.

Two things are worth understanding about Heroku's BAA. First, it's only available through enterprise contracts, not on self-serve plans. Second, the BAA is not a compliance certification. It establishes the contractual relationship that makes Heroku a covered Business Associate. It does not mean Heroku is responsible for your compliance posture.

What Shield doesn't cover (your responsibility)

This is the most important section on this page, and the one most often glossed over.

Shield reduces your infrastructure risk. It does not eliminate your compliance obligations. You remain responsible for a significant portion of what HIPAA requires.

Application-level security and data handling

Shield secures the infrastructure. Your application code is your responsibility. That means: how PHI is collected, processed, stored, and transmitted within your application. Access controls within the application layer. How PHI is handled in logs, error messages, and debugging output. How data is retained, purged, and backed up at the application level.

Infrastructure isolation is not the same as application security.

Access management and SSO

HIPAA requires documented access controls and audit trails for who can access PHI and when. Shield provides infrastructure-level access logging, but access management within your application (user roles, permissions, session management, multi-factor authentication, SSO enforcement) is your design and your responsibility.

Enterprise auditors will ask about this specifically. "We're on Shield" is not a sufficient answer to questions about how access to PHI is controlled and revoked within your product.

Audit evidence generation

One of the most underestimated compliance obligations: producing evidence during audits. Shield provides some infrastructure logging. It does not automatically generate the audit artifacts that auditors and enterprise security reviews typically require.

What teams often need to produce: deployment history showing when specific code changes went to production, configuration change logs, access log summaries by user or role, incident response documentation, and evidence of periodic access reviews. Some of this exists in Shield's logging. Much of it requires custom tooling or manual compilation.

Policy documentation (Administrative Safeguards)

HIPAA's Administrative Safeguards bucket covers policies and procedures that govern how your organization handles PHI. Security management processes, workforce training records, information access management policies, contingency plans, and business associate management. None of this is infrastructure. All of it is required for HIPAA compliance. Shield does not address any of it.

For a detailed breakdown of what your application and infrastructure layers each own, see HIPAA Compliant App Development and HIPAA Hosting Requirements.

Where teams struggle in practice

The gaps between what Shield provides and what auditors actually need are specific and consistent. These are the areas where teams that have come from Shield encounter friction.

Producing deployment audit history

Auditors increasingly ask for records of what code was deployed, when, by whom, and whether it passed security review. Heroku logs deployment events, but producing a coherent deployment audit history (especially one that maps deployments to specific code changes and approvers) requires extracting and organizing data that isn't surfaced in a clean format by default.

Teams that need to demonstrate to an enterprise security team that all production deploys are logged, traceable, and require approval often find this difficult on Heroku.

Explaining Private Space isolation to auditors

Private Spaces provide real isolation. Explaining that isolation to an auditor who isn't familiar with Heroku's architecture requires more work than it should. The question "how is this workload isolated from other customers?" has an answer on Shield, but it's not a simple answer, and the supporting documentation that would make it easy to present is not automatically generated.

Aptible's environment model, by contrast, is designed to produce isolation evidence as a default output of the platform. That distinction shows up during audits in concrete ways.

Demonstrating continuous compliance

Point-in-time audits are being replaced by continuous compliance expectations in enterprise deals and formal HIPAA audits. Demonstrating continuous compliance means showing that controls were active not just today, but consistently over the period under review.

Shield logs can support this, but assembling the evidence requires ongoing effort. The alternative is a platform where continuous compliance evidence is produced automatically as a side effect of normal operations.

Mapping Shield controls to HIPAA safeguards

HIPAA's safeguards (Technical, Administrative, Physical) require specific controls documentation. Shield provides infrastructure controls that satisfy portions of the Technical Safeguards bucket. Mapping those controls to specific HIPAA requirements, in a format that satisfies an auditor or security questionnaire, requires manual work that isn't supported by Heroku's tooling.

What changes under sustaining engineering

The February 2026 sustaining engineering announcement has direct implications for regulated workloads on Heroku Shield.

Under active development, Shield could reasonably be expected to evolve with HIPAA implementation guidance, evolving auditor expectations, and the increasingly sophisticated security reviews that enterprise buyers conduct. Gaps might close. New controls might be added. Compliance tooling might improve.

Under sustaining engineering, none of that is likely. The compliance features that exist today are the compliance features that will exist in two years. Gaps in audit evidence generation, isolation documentation, and continuous compliance tooling are not on a roadmap that will address them.

Enterprise customers are increasingly demanding SOC 2 Type II, HITRUST, and continuous compliance evidence from their infrastructure providers and the products built on top of them. Teams on Heroku Shield who are building toward those requirements may find the platform's compliance posture insufficient not because it regresses, but because the requirements around them advance.

The timing consideration is also practical: compliance migrations are not emergency events. They involve audit continuity planning, BAA transition timing, and careful documentation of the control environment before, during, and after the migration. Teams that know they will eventually need to move should factor audit cycle timing into their migration planning. See What's Happening at Heroku.

When Shield may be sufficient

Not every team running regulated workloads on Heroku needs to migrate. Shield is a real compliance tier with real controls, and it's sufficient for specific scenarios:

• Small teams with limited PHI exposure and no formal external audits in the near term

• Organizations where compliance is managed primarily outside the platform (through application-level controls and policy documentation) and Shield provides the infrastructure baseline needed

• Teams with no enterprise sales cycle that would trigger formal security reviews or security questionnaires

• Workloads where the compliance requirements are stable and not expected to escalate

• Organizations already comfortable with the enterprise contract structure Shield requires

If your compliance requirements are currently met by Shield and you don't foresee that changing in the next 12 to 24 months, migration urgency is low. The caveat is the sustaining engineering posture: controls that don't evolve become relatively weaker as the environment around them does.

When migration becomes necessary

Specific conditions where Shield's constraints become the binding constraint:

• First enterprise deal that includes a formal security review or security questionnaire requiring detailed isolation and audit evidence

• SOC 2 Type II or HITRUST in scope for your organization

• PHI scope expanding significantly (more data types, more integrations, more users with access)

• Auditors asking about isolation in a format Shield doesn't cleanly support

• Continuous compliance evidence required by customers or auditors rather than point-in-time documentation

• Contract renewal triggering procurement review that requires compliance posture documentation

The common thread is escalating external requirements. Shield is not getting worse. The bar around it is getting higher.

If you're already running on Heroku Shield and evaluating alternatives, your migration path includes infrastructure isolation mapping, database export and restore planning, endpoint and DNS cutover, Redis job coordination, and audit validation before and after cutover. For the technical breakdown specific to Shield environments: Migrating from Heroku Shield.

→ See also: Should You Migrate?

Alternatives for regulated workloads

Compliance-first PaaS (Aptible)

Aptible is purpose-built for regulated production workloads. The compliance model is structural rather than tiered: isolation, audit logging, and continuous compliance evidence are defaults of the platform, not add-on configurations.

Aptible holds HITRUST R2 certification, which covers a substantially broader set of compliance controls than SOC 2 alone and is increasingly required in enterprise healthcare deals. The audit activity log has unlimited lookback, deployment history is automatically captured, and environment isolation is designed to produce the documentation that auditors ask for without requiring custom tooling.

For teams whose compliance requirements are growing rather than stable, the distinction between "compliance as a platform design assumption" and "compliance as a premium tier" becomes material. See Heroku vs. Aptible.

Render's HIPAA workspace

Render launched HIPAA-enabled workspaces in 2025. Available on the Organization and Enterprise plans at $250/month (plus a 20% fee on all usage), this option includes access-restricted HIPAA-compliant hosts, SOC 2 Type II, audit logs, and RBAC. A self-serve BAA is available directly from the dashboard. See Render's HIPAA compliance docs for the current setup requirements.

Render's HIPAA workspace is a meaningful improvement over non-compliance PaaS options and is appropriate for teams with straightforward HIPAA requirements. The limitations: no HITRUST, newer compliance infrastructure with a shorter audit track record, and compliance approach that is a workspace tier rather than a platform default. Teams with escalating enterprise requirements may find they outgrow it.

Railway

Railway has a HIPAA BAA available as an enterprise add-on, with a minimum spend threshold for eligibility. SOC 2 Type II and SOC 3 certified. Notable constraint: Railway does not offer managed databases, which means database management, backup, and compliance documentation for database-level controls falls entirely to the customer. See Railway's trust center for current compliance details.

Fly.io

Fly.io offers a HIPAA BAA as a $99/month compliance add-on. SOC 2 Type II certified. Worth noting: Fly.io has accumulated over 554 tracked incidents since 2022 (per status.flyio.net), which creates reliability risk for regulated production workloads where uptime and consistency are compliance-relevant.

DIY Cloud

Moving to AWS, GCP, or Azure provides maximum control over the compliance architecture. You can build exactly the isolation model and audit trail you need. The tradeoff: you own all of it. VPC design, IAM policies, logging infrastructure, database compliance configuration, audit evidence generation, and ongoing maintenance are your responsibility. See DIY Cloud.

Platform compliance comparison table

→ See also: Compare Platforms

Next steps

For teams currently on Heroku Shield or evaluating it:

• Confirm your BAA status and contract terms (including renewal timeline)

• Review your current isolation model and how you would explain it to an auditor

• Audit access controls: who can access PHI, through what paths, and how is that access logged?

• Document your shared responsibility boundaries: what Shield covers, what your application covers, what your policies cover

• Assess your 12 to 24 month compliance roadmap: are your requirements stable or escalating?

• If escalating, evaluate migration runway and factor in audit cycle timing before you're forced to move under pressure

See: Migration Guide, Heroku vs. Aptible, Migrating from Heroku Shield