We Started on a Managed PaaS, Now We Need SOC 2 and Our Own VPC: Where Do You Go? (7 BYOC Options Compared)

Key points

• SOC 2 does not require hosting in your own cloud account. The AICPA Trust Services Criteria are control-and-evidence based and name no hosting architecture, so a shared-tenant PaaS like Render or Heroku can hold a clean SOC 2 Type II report. What forces the move is an enterprise security questionnaire, a subprocessor restriction, or a data residency clause in a contract.
• Managed PaaS platforms such as Render and Heroku run your containers in cloud accounts those vendors own. Private networking and VPC peering do not change that, so no configuration on those platforms satisfies a contract clause that says customer data must stay in an account you control.
• Seven credible options deploy into your own cloud account: Qovery, Porter, Northflank's BYOC tier, Flightcontrol, DuploCloud, plus self-run Red Hat OpenShift or SUSE Rancher. Qovery, Porter and Northflank are Kubernetes-based and multi-cloud; Flightcontrol is AWS-only on ECS and Fargate; DuploCloud leads with compliance control mapping.
• Qovery deploys into your own AWS, GCP, Azure or Scaleway account, or onto a Kubernetes cluster you already run, and keeps the PaaS workflow: git-push deploys, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.
• Budget 2 to 6 weeks for a 5 to 20 service migration: containerize anything on buildpacks, move Postgres and Redis to managed cloud services, re-map secrets, run both stacks in parallel, then cut DNS over with a low TTL.
• BYOC usually wins on cost above roughly $2,000 to $3,000 a month of PaaS spend because you pay cloud list price minus your own Savings Plans or committed-use discounts, but you pay a managed Kubernetes control plane fee floor that a hobby PaaS plan does not have.

SOC 2 has never once required anyone to leave a managed PaaS. An enterprise customer's security questionnaire did, or a data residency clause buried in a master service agreement, or a security team that wanted its own logs. I have watched this exact moment play out in a lot of the CTO conversations I sit in on, and the trigger is almost never the audit. It is a deal.

So if you are on Render or Heroku and someone just told you your data has to live in your own AWS account, the first thing to know is that you are not fixing a compliance gap. You are answering a contract. That reframing matters, because it changes which platform you should move to and how fast you actually need to move. This article walks the whole decision: what SOC 2 really asks for, where a managed PaaS actually runs your code, the seven platforms that deploy into an account you own, and what the move costs in time and money.

Does SOC 2 actually require you to move off a managed PaaS into your own cloud account?

No. SOC 2 imposes no hosting architecture at all. The AICPA Trust Services Criteria judge your controls and your evidence against five categories - Security, Availability, Processing Integrity, Confidentiality, and Privacy - and they are technology-neutral by design (AICPA). Only the Security category, the common criteria, is required for every SOC 2; the other four are in scope only if you choose them. Nothing in that framework says where your servers sit.

A SOC 2 Type II report tests whether your controls actually operated over an observation window, usually three to twelve months, and the audit fee itself typically runs from $10,000 to $50,000 (Vanta). None of that machinery cares whether your compute runs in a Render account or your own.

Here is the part that stops people blaming the auditor: when you host on a shared-tenant PaaS, that vendor becomes a subprocessor, and you inherit their SOC 2 report as evidence for the infrastructure layer. Render publishes a SOC 2 Type II attestation covering security, confidentiality and availability (Render), and Heroku publishes SOC 1, SOC 2 and SOC 3 reports along with ISO 27001 and PCI DSS Level 1 (Heroku). These are good products with real reports. Your auditor will accept them.

Your enterprise buyer's security team often will not. Their questionnaire does not ask "is your host SOC 2 certified." It asks where customer data resides, which named subprocessors touch it, and whether you can produce raw CloudTrail, VPC flow logs and evidence of who holds the KMS keys. A vendor attestation letter is a different artifact from your own account's logs, and the people writing these questionnaires know the difference. Security and compliance now gate deals hard: in one 2025 buyer survey, 63% of respondents said they actively seek detailed security and compliance information before they will even engage a vendor, and 31% said compliance was a decisive factor in final vendor selection (Kiteworks).

In the conversations I have, the real triggers to move show up in this rough order: an enterprise deal with a data residency clause, a customer vendor security review that rejects shared tenancy, HIPAA or GDPR or DORA adjacency, a security team that wants custody of its own logs and encryption keys, and finally cost at scale. Notice the audit is not on that list.

The honest counter-case: if no customer has asked, no contract names residency, and you are spending under roughly $2,000 to $3,000 a month on hosting, moving now is premature. A pre-revenue startup or a team selling to SMBs that never send a questionnaire should stay on Render or Heroku and keep shipping. Move when a deal, a regulator, or your own bill makes you.

Where does a managed PaaS like Render or Heroku actually run your workloads?

Render and Heroku execute your containers inside cloud infrastructure those vendors own and operate. You get real isolation features, but you never get a deployment into an AWS, GCP, Azure or Scaleway account with your name on the bill and your IAM at the boundary. The managed PaaS bargain is simple: the vendor owns the cloud account, the cluster, the IAM boundary and the cloud invoice, and you own the application and, logically, the data.

Render offers private services that are unreachable from the public internet, private networking between your services in the same region and workspace, and Private Link out to your own AWS VPC (Render). That last feature gets mistaken for BYOC, but it is a one-directional link from Render's infrastructure to your external VPC, not your workload running inside your account. The compute still lives in Render-operated infrastructure.

Heroku is the same shape with older bones. Dynos run in AWS accounts that Salesforce operates; a Heroku region maps directly to an AWS region under the hood (Heroku). Private Spaces give you an isolated network for dynos, and Shield Private Spaces add the controls for regulated workloads such as HIPAA and PCI (Heroku). Strong isolation, still Heroku's account.

This is exactly what decides a questionnaire answer. "Data is encrypted and tenant-isolated in our vendor's environment" is a materially different sentence from "data never leaves an account we control, and here are our VPC flow logs." One passes a startup security review. The other passes a Fortune 500 one.

There is a cost consequence nobody raises on the sales call. Because the vendor owns the account, your AWS Compute Savings Plans, your GCP committed-use discounts, your Azure reservations and any negotiated enterprise agreement cannot apply to that workload. You are paying the vendor's margin on top of compute you could otherwise buy at your own discounted rate.

What should "migration friendly" mean when you move to your own AWS, GCP, Azure or Scaleway account?

A migration-friendly platform keeps the git-push workflow you had on your managed PaaS while the compute, data plane and cloud bill move into your own account, and it leaves behind standard artifacts - container images, Kubernetes manifests, Terraform - so your workload keeps serving traffic even if you cancel the subscription. If moving off Heroku just means getting locked into a different proprietary runtime, you have not solved the problem you were paying to solve.

Run every vendor through five criteria: (1) it deploys into your own cloud account, (2) it keeps a PaaS-grade developer experience, (3) it uses standard primitives you could operate without the vendor, (4) it gives you preview environments plus per-environment access control, and (5) the artifacts it produces are yours to export. The single sharpest question to ask on any vendor call is this: if we cancel tomorrow, what keeps running in our account, and for how long without your control plane?

A few practical realities shape the timeline. Dockerfile-based services move in days. Apps still built on Heroku buildpacks or any non-container build system need a containerization step first, and that is usually the longest task in the whole project. For data, put Postgres and Redis on managed cloud services - Amazon RDS, Google Cloud SQL, Azure Database, or Scaleway managed databases - rather than a container you babysit, because auditors want automated backups, encryption at rest, and a restore you have actually tested.

Then the subprocessor question that decides your questionnaire answer: does the platform's control plane hold your secrets and build logs, or only metadata? Get that in writing, because it determines whether the platform vendor still shows up as a subprocessor after you move. Last, know that bring-your-own-cluster is a separate capability from BYOC. Some platforms will only create and own a fresh cluster for you; others attach to the EKS, GKE, AKS or on-prem cluster you already run. If you have already invested in a cluster, that distinction is the whole game.

Which platforms deploy into your own cloud account instead of the vendor's?

Seven options deploy into an account you own: Qovery, Porter, Northflank's BYOC tier, Flightcontrol, DuploCloud, and self-run Red Hat OpenShift or SUSE Rancher. Qovery, Porter and Northflank are Kubernetes-based and multi-cloud. Flightcontrol is AWS-only on ECS and Fargate. DuploCloud leads with SOC 2, HIPAA and PCI control mapping baked into provisioning. OpenShift and Rancher are distributions you run yourself.

Split them into three buckets so you can self-select fast. PaaS-style BYOC is Qovery, Porter, Northflank's BYOC tier and Flightcontrol. Compliance-automation-first is DuploCloud. Self-run Kubernetes distributions are OpenShift and Rancher.

The single hardest filter is AWS-only versus multi-cloud. If you run on GCP, Azure, Scaleway, or an existing cluster, Flightcontrol drops off your shortlist immediately, however good it is on AWS. Runtime is the next filter, because it decides portability and hiring: Kubernetes gives you a large labor market and a documented exit path, while ECS and Fargate give you simpler operations at the price of tighter AWS lock-in.

Qovery, stated precisely and once: it deploys into your own AWS, GCP, Azure or Scaleway account, or onto a Kubernetes cluster you already run through bring-your-own-Kubernetes (Qovery docs). It keeps the PaaS workflow with git-push deploys, preview environments created automatically for each pull request (Qovery), environment auto-stop for non-production, automated managed cluster upgrades and node patching, role-based access control with granular per-project and per-environment permissions, and databases backed by managed cloud services such as an RDS instance on AWS (Qovery docs). For the record, Qovery itself holds a SOC 2 Type II report (Qovery), though that is Qovery's own posture, not yours.

Porter and Northflank are credible direct competitors, and I will only compare them on axes you can verify. Porter runs on Kubernetes in your own AWS, GCP or Azure account and can attach an existing cluster on its Enterprise tier (Porter). Northflank has the widest cloud coverage of the group, deploying into AWS, GCP, Azure, Oracle Cloud and CoreWeave, and it can import an existing EKS, GKE, AKS or self-managed cluster through its BYOK model (Northflank). Flightcontrol, which is transitioning to the name Ravion in 2026, provisions ECS, Fargate, RDS and other AWS primitives directly in your AWS account (Flightcontrol). DuploCloud provisions into your own AWS, Azure or GCP account and maps controls to SOC 2, HIPAA, PCI, NIST and more at provisioning time (DuploCloud).

Verify every row on a first-party page before you commit. I checked each of these on the vendors' own sites, and the same discipline applies to any feature or price you are tempted to assume.

How does BYOC change what you hand your SOC 2 auditor?

BYOC does not make you compliant. It relocates the technical controls into infrastructure your auditor and your compliance tool can inspect directly. The day your workload lands in your own account, CloudTrail audit logs, VPC flow logs, KMS key custody, IAM policies and backup and restore evidence are all generated by services your auditor already knows how to sample, inside a boundary you own.

That maps cleanly onto the AWS Shared Responsibility Model. In your own account, AWS states that customers are responsible for managing their data including encryption options, classifying their assets, and using IAM tools to apply the appropriate permissions (AWS). That responsibility set is almost exactly the evidence an auditor samples, which is why owning the account makes the evidence collection so much more direct.

Say the limits bluntly, though. BYOC does nothing for change management, access reviews, incident response, vendor management, or onboarding and offboarding. Those are platform-independent controls you have to run no matter where your compute lives. And the platform can remain a subprocessor even under BYOC, through control plane metadata, build logs and secret handling. Ask each vendor exactly what leaves your account and put the answer in your subprocessor register.

Two vendors earn specific credit here. DuploCloud's real differentiator is opinionated SOC 2, HIPAA and PCI control mapping applied at provisioning time rather than checked after the fact (DuploCloud). Qovery's contribution to the evidence pile is narrower and honest: per-environment RBAC for least privilege, and a deployment history you can sample for change management, while the data plane and logs stay in your account. Whatever you pick, pair it with a compliance automation tool like Vanta, Drata or Secureframe. No deployment platform is a compliance program, and that includes Qovery.

How long does a managed PaaS to BYOC migration take, and what are the steps?

A 5 to 20 service application typically takes 2 to 6 weeks to move off a managed PaaS like Render or Heroku, and the sequence is the same on any BYOC platform. Inventory, containerize, stand up the target account, migrate data, run both stacks in parallel, then cut DNS over with a low TTL and keep a rollback window.

• Step 1, inventory everything. Services, cron jobs, background workers, environment variables and secrets, managed Postgres and Redis, object storage, egress IPs, custom domains, webhooks and third-party allowlists. The thing you forget here is the thing that pages you at 2am after cutover.
• Step 2, containerize anything still on buildpacks. Prove every image builds reproducibly in CI and runs locally before you touch infrastructure. Dockerfile services skip most of this step.
• Step 3, stand up the target account. VPC and subnets, IAM roles, the platform's cluster or installer, and a staging environment that mirrors production before production exists.
• Step 4, migrate data. Use pg_dump and pg_restore for small datasets, and logical replication when you need near-zero downtime. Test the restore before you need it, not after.
• Step 5, run both stacks in parallel. Mirror or dual-write traffic where you can, and compare p95 latency and error rates for several days before you commit to the new stack.
• Step 6, cut DNS over on a low TTL. Keep the old stack warm through the rollback window, then decommission it and remove the vendor from your subprocessor list and your questionnaire answers.

Six pitfalls burn teams over and over: hardcoded internal hostnames, customer-registered egress IP allowlists that break when your IPs change, duplicated background jobs firing from both stacks during the parallel run, secrets copied across without rotation, preview environments that need their own cost ceiling, and cutting over before the restore test actually passes. The last one is not optional.

What does BYOC cost compared with staying on a managed PaaS?

Below roughly $2,000 to $3,000 a month of managed PaaS spend, staying on Render or Heroku is usually cheaper once you price in engineering time. Above it, BYOC generally wins, because you pay cloud list price minus your own discounts plus a flat platform fee, instead of the vendor's margin on managed compute. Model three buckets separately or the comparison is meaningless: cloud resources, platform subscription, and engineering time.

The discount argument is where BYOC gets its edge, and the published numbers are real. AWS Compute Savings Plans cut compute cost by up to 66% versus on-demand (AWS). GCP committed-use discounts reach up to 70% for memory-optimized machine series and up to 55% for other series (Google Cloud). Azure reserved VM instances save up to 72% compared with pay-as-you-go (Microsoft Azure). On a managed PaaS, none of those apply to your workload, because the account is not yours.

Now the honest BYOC floor. A managed Kubernetes control plane is not free. Amazon EKS charges $0.10 per cluster per hour, about $73 a month (AWS), and GKE charges the same flat $0.10 per cluster per hour, though it credits $74.40 a month, enough to make one cluster effectively free (Google Cloud). Azure AKS gives you a Free control plane tier with no per-cluster charge, moving to $0.10 per cluster per hour on the Standard tier (Microsoft Azure). So a five-service app can genuinely cost more in your own account than on a small PaaS plan, once you add that floor to node cost.

Platform fees vary in how openly they are published. Porter's Standard tier is usage-based at published per-vCPU and per-GB rates, with Enterprise quote-only (Porter). Northflank publishes pay-as-you-go consumption rates, with Enterprise quote-only (Northflank). Flightcontrol publishes a $97 Starter and a $397 Business tier, with preview environments and RBAC on the Business tier (Flightcontrol). DuploCloud does not publish pricing; it is quote-only. Qovery publishes its tiers on its pricing page.

The comparison people skip is headcount. The average total compensation for a DevOps engineer in the United States is about $170,500 (Levels.fyi), so a single platform hire costs more per year than most platform subscriptions cost in a decade. And there is a cost lever specific to BYOC platforms: environment auto-stop for non-production removes idle spend that a per-service PaaS plan keeps billing. That matters when wasted cloud spend hit 29% of cloud budgets in the most recent Flexera survey (Flexera).

When should you skip the platform and run Kubernetes yourself?

Run Kubernetes yourself with OpenShift, Rancher, or Terraform plus Argo CD when you already staff two or more full-time platform engineers and have a requirement no vendor can meet: air-gapped or sovereign deployment, heavy regulatory customization, or a sunk OpenShift investment. Below that headcount, you are rebuilding a product you could buy this week.

The recurring cost nobody budgets is the upgrade treadmill. Kubernetes ships roughly three minor releases a year and supports each one for only about 14 months of patches (Kubernetes). That means version upgrades, CVE patching, add-on drift, ingress and certificate rotation, permanently, not once. Someone owns that forever, and that someone is expensive.

DIY genuinely wins in a few places: air-gapped or sovereign environments, unusual regulatory customization, existing OpenShift or Rancher licenses you have already paid for, and workloads no PaaS abstraction fits. Red Hat OpenShift is a mature enterprise Kubernetes platform for exactly these cases, sold on quote-based subscriptions (Red Hat), and SUSE Rancher is open source and free at its core, with a paid Rancher Prime tier for support (SUSE).

A BYOC platform wins the opposite situation: a small team, a compliance deadline with an actual date on it, and preview environments needed this quarter rather than next year. Most teams do not have two platform engineers to spare. Only about 28% of organizations report a dedicated platform engineering team (CNCF), and DORA's research has found that internal developer platforms lift individual productivity and team performance even as throughput and stability dip during the adoption J-curve (DORA). A platform layer is how a small team gets that lift without the headcount.

The middle path most teams miss is to keep the cluster you already run and put a platform layer on top of it. Qovery, Porter and Northflank all support attaching an existing Kubernetes cluster, so you are not throwing away the EKS or GKE work you have already done. Before you sign anything, run the exit test: can you export manifests and Terraform, and does the workload keep serving traffic if the vendor's control plane goes dark for a week? If the answer is yes, you have kept your escape hatch. If it is no, you have swapped one lock-in for another.