Does Railway Support VPC Isolation? (And Why It Matters for Compliance)
The short answer: no. Railway does not support VPC (Virtual Private Cloud) isolation.
Your application on Railway runs on shared infrastructure. You don't control the network boundaries between your app and other tenants. You don't get private subnets, security groups, or network-level isolation between your production and staging environments. And you can't prove to a security auditor that your database is only accessible from within a private network — because it isn't.
For a lot of startups, this doesn't matter. If you're early-stage, moving fast, and the only people using your app are your own team and a handful of early users, shared infrastructure is fine. Railway is excellent for that phase.
The tradeoffs show up when real compliance requirements arrive.
What VPC Isolation Actually Is
A VPC (Virtual Private Cloud) is a logically isolated section of a cloud provider's network that you control. You define the IP address range. You set up subnets — public and private. You configure security groups that control which resources can talk to which other resources. You provision NAT gateways that let private resources reach the internet without being reachable from it.
When your application runs in a VPC:
- Your database is in a private subnet — not accessible from the public internet, only from within your own VPC
- Your production environment and staging environment are isolated networks — a misconfigured staging app cannot reach your production database
- You have a complete, auditable record of which resources can communicate with which at the network level
- Your containers run on compute that is logically isolated from other tenants' workloads
Railway provisions infrastructure for you, but it's Railway's infrastructure — not yours. You don't own the network. You don't control the security groups. You can't configure private subnets. The VPC concept doesn't apply.
Why It Matters for SOC 2
SOC 2 is the most common compliance framework startups encounter. Your first enterprise customer will ask for it. Your first healthcare or fintech partnership will require it.
SOC 2 Trust Service Criteria require evidence of network-level controls. Specifically:
CC6.1 — Logical and physical access controls: The organization implements logical access security measures to protect against unauthorized access. "Our infrastructure is hosted on Railway" is not evidence of logical access control. "Our production database is in a private subnet, accessible only from within our application VPC, with security group rules restricting inbound access to the application tier" is.
CC6.6 — Transmission of data: Logical access controls are in place to prevent unauthorized users from accessing systems or data. VPC isolation — network-level separation between environments, private subnets for databases, security group rules — is the technical control that satisfies this criterion.
CC6.7 — Monitoring infrastructure: The organization monitors infrastructure for unauthorized activity. This requires network flow logs, VPC traffic logs, and security group audit trails. These don't exist when you're running on shared cloud infrastructure you don't own.
Your SOC 2 auditor will ask where your database is, who can access it, what controls prevent network-level access from outside your application tier, and how you've isolated production from staging. On Railway, there are no satisfactory answers to these questions.
Why It Matters for HIPAA
If you're building in healthcare — a patient-facing app, a clinical workflow tool, an EHR integration — HIPAA's Security Rule applies.
The Security Rule's technical safeguards require:
- Access control: Unique user identification and automatic logoff for ePHI systems. This includes database-level access controls enforced at the network layer, not just at the application layer.
- Transmission security: ePHI transmitted over electronic networks must be protected against unauthorized access. Encryption in transit is table stakes — but so is ensuring that transmission paths are over controlled, private network routes.
- Audit controls: Hardware, software, and/or procedural mechanisms that record and examine activity in systems that contain ePHI. Network flow logs from a VPC are part of this audit trail.
"We host on Railway" doesn't satisfy these requirements. "We run in an isolated AWS VPC with encrypted RDS in a private subnet, network flow logging enabled, and security group rules that restrict database access to our application tier only" does.
Why It Matters for Enterprise Security Reviews
Even outside formal compliance frameworks — SOC 2, HIPAA, PCI-DSS — enterprise customers do security reviews before signing contracts. Most of them include a questionnaire. Some include a penetration test or architecture review.
Common questions you'll be asked:
- "Is your database publicly accessible?"
- "Are your production and staging environments network-isolated from each other?"
- "Do you have VPC-level controls in place to prevent lateral movement between your application and database tiers?"
- "Can you provide network architecture diagrams showing isolation between environments?"
On Railway, you cannot answer these questions favorably. Your database is accessible via Railway's infrastructure. Your production and staging environments are not network-isolated — they both run on Railway's shared network. There are no VPC controls because there is no VPC.
This doesn't necessarily kill the deal at every enterprise — but it will slow it down, require additional compensating controls, and sometimes be a flat dealbreaker for procurement and security teams who have specific infrastructure requirements.
What VPC Isolation Looks Like on AWS
On AWS, a properly isolated startup infrastructure looks like this:
Production VPC: a private network with dedicated CIDR range (e.g., 10.0.0.0/16). Two availability zones. Public subnets for the application load balancer. Private subnets for ECS tasks and RDS. A NAT gateway so private resources can reach the internet for outbound requests. Internet gateway for inbound traffic to the load balancer only.
Staging VPC: identical structure, separate CIDR range (e.g., 10.1.0.0/16). No peering connection to production. Production and staging cannot communicate — a bug in staging, a misconfigured environment variable, a compromised staging credential — none of it reaches production.
Security groups: explicit rules per resource. The load balancer accepts inbound on 443. The ECS tasks accept inbound only from the load balancer's security group. The RDS instance accepts inbound only from the ECS task's security group. Nothing else can reach your database — including someone with AWS console access who doesn't have the right security group permissions.
Network flow logs: VPC flow logs capture all network traffic to and from your resources. You have an audit trail of every connection attempt, success, and rejection.
This is the standard. It's what SOC 2 auditors expect. It's what enterprise security reviewers want to see. And it's not available on Railway.
How NoahOps Handles This
NoahOps provisions this infrastructure automatically in your AWS account.
When you create a production environment, NoahOps provisions a VPC with isolated private subnets, configures ECS Fargate tasks to run in private subnets behind an Application Load Balancer, provisions RDS PostgreSQL in a private subnet with no public accessibility, and wires the security group rules so only your application tier can reach your database.
When you create a staging environment, it gets its own VPC — isolated from production at the network level.
The same push-to-deploy experience as Railway. The same no-YAML, no-Terraform interface. But the infrastructure is real AWS, in your account, with the VPC isolation, private subnets, and security group controls that compliance frameworks require.
If you're approaching SOC 2, starting a HIPAA-covered product, or beginning to close enterprise deals, the time to migrate is before the first auditor question — not after.
Request a free demo at noahops.com and see your VPC-isolated environment provisioned in under 15 minutes.
FAQ
Does Railway have any network isolation features?
Railway offers private networking within a Railway project — services within the same project can communicate over a private network. But this is not the same as VPC isolation. It doesn't give you control over the network architecture, private subnets, security groups, or the isolation between your infrastructure and other Railway tenants. It also doesn't satisfy the network control requirements that SOC 2, HIPAA, or enterprise security reviews look for.
Can I add VPC isolation to Railway later?
No. VPC isolation requires migrating to infrastructure where you own and control the network layer — AWS, GCP, or Azure. You can't bolt VPC controls onto Railway's managed infrastructure. The migration is the path.
How long does it take to get VPC-isolated infrastructure on NoahOps?
For a typical startup stack — one or two services, Postgres, maybe Redis — your first production environment with full VPC isolation is ready in under 15 minutes after connecting your AWS account. The infrastructure NoahOps provisions is the same you'd spend weeks building manually with Terraform.
Will SOC 2 auditors accept AWS with NoahOps as the management layer?
Yes. SOC 2 audits are about the controls in place on your infrastructure — not about who helped you provision it. Your auditor will review your VPC configuration, security group rules, RDS access controls, and logging setup. NoahOps provisions all of these in your AWS account, and you can show the auditor the AWS console directly. NoahOps is the tooling; AWS is the infrastructure.
What if I already have SOC 2 on Railway?
It's possible to achieve SOC 2 on Railway with sufficient compensating controls — encryption in transit and at rest, strong application-level access controls, and security policies that compensate for the lack of network isolation. But it's harder, the resulting SOC 2 report will have more caveats, and as your enterprise pipeline grows, customers' security teams will push back on the architecture. Most teams who achieve SOC 2 on Railway end up migrating to proper VPC-isolated infrastructure at the next renewal cycle anyway.