Why Compliance Teams Reject Heroku and Railway (and What to Do Instead)

The email is always some version of the same thing: "Legal won't approve Heroku for this data." If you are building anything that touches health records, financial data, or a large enterprise's internal information, sooner or later a compliance team blocks your deployment platform — and the answer for regulated workloads is almost always a HIPAA-compliant app deployment on AWS (or the customer's own cloud) rather than a multi-tenant PaaS. Here is why the rejection happens and what actually gets through review.

Why multi-tenant PaaS fails procurement

Heroku, Railway, and similar platforms are excellent products. They fail regulated procurement for structural reasons, not quality ones:

• Shared tenancy. Your app runs alongside thousands of others on infrastructure you don't control. For a HIPAA or SOC 2 auditor, "other tenants are isolated by the platform" is a control you cannot evidence yourself — you are inheriting someone else's attestation, and the reviewer has to accept the whole chain.
• The BAA problem. HIPAA requires a Business Associate Agreement with every party that touches protected health information. Many PaaS providers either won't sign one, or only on a top enterprise tier, and even then you are adding another subprocessor to a chain the customer has to review and approve.
• Limited visibility and control. You often can't choose the exact region, can't bring your own encryption keys, can't get infrastructure-level audit logs, and can't prove where a given byte of data physically lives. Auditors ask all four.
• Data residency and sovereignty. If a contract requires data to stay in a specific country or in infrastructure the customer controls, a platform that manages placement for you is a non-starter — you can't promise what you can't control.

None of this means the PaaS is insecure. It means the evidence model doesn't fit. Compliance is not "is it safe" — it is "can you prove it, with artifacts, on our terms." Multi-tenant platforms are built to abstract those artifacts away, which is exactly what makes them pleasant to use and unusable for the review.

What SOC 2 and HIPAA actually ask for

Strip away the acronyms and the recurring requirements are concrete:

• Encryption at rest and in transit, ideally with keys you control (KMS with a customer-managed key).
• Access control and least privilege, with logs of who accessed what.
• Audit trails at the infrastructure and application layers, retained and tamper-evident.
• Network isolation — private subnets, no database on the public internet.
• A signed BAA (for HIPAA) with each entity in the data path.
• Data locality you can name and prove.

On a hyperscaler like AWS, every one of these maps to a service you configure and can evidence: KMS, IAM, CloudTrail, VPC, and AWS's own BAA, which they sign and which covers the HIPAA-eligible services. That is the difference — you are assembling controls you can point an auditor at, not inheriting an abstraction.

The own-cloud alternative

There are two ways through, and they sit on a spectrum.

Option one: run it in your own AWS account, properly. A dedicated, single-tenant deployment on AWS with the controls above, an AWS BAA in place, and everything defined in code so it is auditable. This clears most SOC 2 and HIPAA reviews and keeps you in control of one environment.

Option two: run it in the customer's cloud (BYOC). For the strictest buyers — a hospital network, a bank, a government contractor — even your compliant AWS account is "another vendor's cloud." Here the data never leaves their account; you deploy into it and operate via short-lived, least-privilege access. This is the model that turns a hard "no" into a "yes," and the mechanics — cross-account roles, Terraform, audit logging the customer already trusts — are covered in deploying SaaS inside a customer's AWS VPC. If you're still deciding whether you need it at all, start with what BYOC is and when you need it.

How to know which one you need

Read the contract and the security questionnaire before you architect anything. If it asks for a BAA, encryption with customer-managed keys, and named data residency, a properly configured AWS account is your floor. If it says the data must remain in infrastructure the customer controls — or their procurement team simply won't approve any external cloud — you need BYOC. The mistake is discovering which one after you have already built on a platform that can't clear either bar, and having to re-platform mid-deal. It is the same ceiling that eventually forces teams off Railway, Render, and Vercel when they move upmarket.

Getting a regulated deployment right the first time — the encryption, the IAM, the audit trails, the BAA, the network design — is detailed, unforgiving work, and a failed audit is expensive in both time and trust. If you have a compliance-blocked deal on the table and no in-house infrastructure team, having someone build the compliant deployment for you is often the fastest way to unblock it.