PaaS platforms that deploy into your own cloud account

A new category of PaaS splits the platform in two: the vendor keeps the control plane, but every workload, database, and byte of your data runs inside your own AWS, GCP, or Azure account. You get click-to-deploy ease comparable to Heroku, while your infrastructure stays out of someone else's shared tenant. I've watched teams burn weeks migrating off platforms that promised simplicity and delivered a black box instead, so this shift matters more than it might sound at first.

The architecture is the point, so let me be precise about it. In a Bring Your Own Cloud (BYOC) PaaS, the vendor runs the dashboard, the CI/CD orchestration, the Kubernetes management layer, all the stuff that makes deployment feel effortless. The runtime, meaning the actual compute, storage, and data, never leaves your cloud account. Compare that to Heroku, where your app runs on infrastructure you can't see and don't control. Or compare it to raw Kubernetes, where you own everything but need a platform team just to keep the lights on. BYOC sits in the gap: the vendor handles the grind of running Kubernetes, you keep the account where your data actually lives.

People throw around "BYOC" and "self-hosted PaaS" like they're the same thing. They're close, but the gap between them matters. Self-hosted usually means the whole platform, control plane and all, runs on your infrastructure. BYOC is narrower: the vendor's control plane stays SaaS, and only the runtime moves into your account. Get this distinction straight before you start talking to vendors, because it changes what you're actually buying.

Why the traditional PaaS tradeoff has become harder to accept

Lock-in on a traditional PaaS isn't bad luck. It's structural. Once you've built your deployment pipeline, your add-ons, and your environment config around a platform's specific quirks, none of it transfers cleanly anywhere else. Moving off means rebuilding, not migrating, and anyone who's tried it knows the difference in your bones.

Heroku is the case study everyone points to, and for good reason. The platform moved into what Salesforce calls sustaining engineering in early 2026 and stopped signing new Enterprise Account contracts. That signals a platform being kept alive at cruising altitude, not one still climbing. Build your company on that foundation and you're planning your infrastructure roadmap around someone else's decision to stop building.

Reliability backs this up, and the numbers aren't flattering. Heroku had a 15-hour, 45-minute outage on June 10, 2025. Eight days later, on June 18, another incident took it down for 8 hours and 30 minutes. Teams running on that platform had zero access to the underlying infrastructure during either event. No way to diagnose, no way to fail over, nothing to do but refresh a status page and wait.

Cost is the other half of it. Heroku's Hobby tier starts at $5 per dyno per month; Standard runs $25. Fine at small scale. Add a staging environment, a managed Postgres instance, a few extra dynos for background jobs, and the bill compounds fast with zero visibility into what's actually driving it. You're paying a markup on cloud infrastructure you never get to see, let alone optimize.

Compliance isn't optional anymore either, not for most startups selling into enterprise or working in a regulated space. Data residency and audit requirements show up early. Traditional PaaS platforms make those hard to satisfy cleanly, because you don't control the infrastructure boundary. The obvious fallback, raw Kubernetes, solves that control problem while reintroducing the exact operational toil PaaS was built to remove in the first place.

What the BYOC model actually changes for compliance and data sovereignty

Here's the mechanical shift that matters: because every workload runs inside your own VPC, your data never transits or rests on the vendor's infrastructure. Your cloud account becomes the real security boundary, rather than a shared environment you're trusting some third party to segment correctly.

That changes what a compliance audit actually looks like. A HIPAA Business Associate Agreement and a SOC 2 scope both get simpler, because auditors examine your AWS, GCP, or Azure environment directly instead of trying to evaluate a shared-tenant platform they can't see into and just have to take the vendor's word on. On a BYOC PaaS, network policies, encryption settings, and access controls get configured through the platform itself, rather than becoming a separate multi-month engineering project bolted on after the fact.

Data residency follows the same logic. Need workloads pinned to a specific region for GDPR or a data-localization clause in a contract? On BYOC, that's a configuration choice. On a traditional PaaS that abstracts the underlying cloud away entirely, it's often something you can't guarantee at all, because you don't know, and can't control, where things actually run.

There's an operational upside too, and it's easy to miss. CVE patching and cluster upgrades still happen automatically, since the vendor manages the Kubernetes layer sitting inside your account. You get the patching cadence of a managed platform without hiring someone whose entire job is keeping that layer current. The compliance posture ends up owned rather than rented: your account holds the audit trail, the logs, the configuration state. When an auditor asks for evidence, you're not waiting on a vendor to dig it up from a system you can't see into.

The platforms in this category and what distinguishes them

A handful of platforms have built this out, and they're not solving the same problem in the same way.

Porter deploys production-ready environments directly into a customer's AWS, GCP, or Azure account, provisioning and managing the Kubernetes clusters underneath. It covers VPC setup, CI/CD, autoscaling, preview environments, GPU workloads, and one-click SOC 2 and HIPAA compliance. Pricing is resource-based, not seat-based. There's a dedicated startup program, and it's built for teams that want to move fast without standing up a DevOps function.

Encore Cloud takes a different angle. Application infrastructure lives in the customer's AWS or GCP account from day one, and the open-source CLI builds applications as portable Docker containers. The managed cloud layer automates deployment on top without ever taking custody of the underlying data or compute.

Coolify goes fully open-source and self-hostable, with no vendor control plane at all. You deploy to your own servers or VPS over SSH, and it handles static sites, full-stack apps, and one-click services with automated SSL. You run everything, platform layer included.

Dokku is the minimalist option. Single-server, git-push deployment, builds via Dockerfiles or buildpacks. Good fit for a solo developer or a small team chasing that old Heroku-style workflow, minus the multi-node complexity.

Cloud Foundry runs on Kubernetes underneath and deploys anywhere via BOSH. Built for bigger organizations that want an open-source, enterprise-grade PaaS they run entirely in-house.

When you're comparing these, a few things actually matter: which clouds are supported, whether compliance automation is built in or something you configure by hand, how much operational load sits on you versus the vendor, GPU support, and whether pricing tracks seats or actual resource use. The open-source self-hosted tools trade vendor convenience for full ownership, which is the right call if you've got the bandwidth to run the platform layer yourself. The managed BYOC platforms take that layer off your plate so your team can stay on product.

How BYOC PaaS fits the infrastructure needs of AI startups specifically

AI companies are, almost by default, already living inside hyperscale cloud accounts. Most AI startups now run primarily on cloud GPU resources rather than on-prem hardware, which means the infrastructure decision has effectively already been made before the platform conversation even starts. For these teams, BYOC formalizes where they already are rather than asking them to leap somewhere new.

Cost visibility matters more here too. Early-stage AI startups often spend somewhere in the $2,000 to $8,000 a month range on cloud infrastructure during prototyping. At that range, pricing tied to actual usage isn't a nice-to-have; it's the difference between a burn rate you understand and one you're guessing at every month-end.

GPU access is its own argument for BYOC. To get reserved capacity, committed-use discounts, or specialized instance types like AWS P4d and P5, GCP's A3, Azure's NDv5, you need to be running inside your own cloud account in the first place. A shared, abstracted PaaS can't expose that kind of infrastructure. It was never built to.

Then there's speed. Training and inference pipelines iterate constantly, and the ability to spin environments up and tear them down without provisioning friction ties directly to how fast a model actually improves. Training data and fine-tuning datasets are often the single most valuable thing an AI company owns, too, and running that through a shared-tenant platform introduces a custody risk most teams won't accept once they sit down and think it through. A BYOC PaaS that handles GPU scheduling and cluster management inside your own account lets a five-person AI engineering team move at a pace that would otherwise take a whole platform org.

What to look for when evaluating a BYOC PaaS for a growing team

Start with onboarding. Does the platform provision a fresh VPC for you, or does it expect you to pre-configure the networking before it'll even connect? The cleaner that handoff, the lower your migration risk going in.

Don't take compliance automation on faith. SOC 2 and HIPAA readiness should come from configuring the platform itself, not from a separate professional services contract bolted on top. Ask directly whether the platform generates audit-ready evidence, or whether it just claims compliance support without producing anything an auditor can actually use.

Get explicit about the operational handoff, too. What does the vendor manage: cluster upgrades, CVE patches, autoscaling? What stays yours: application code, secrets, data? Any fuzziness here is exactly where things fall apart mid-incident, when nobody's sure whose job it was to catch the problem.

If you're an AI team, confirm the platform supports the specific GPU instance families you actually need, and that it can schedule those jobs without forcing you to bolt on separate tooling outside the platform. That's often the whole reason the platform choice matters.

Look hard at the pricing model. Resource-based pricing tied to what you actually consume is a fundamentally different deal than per-seat or per-dyno pricing, where idle capacity still costs you money every single month.

Last thing: think about your exit before you need one. Because the workloads already sit in your own cloud account, walking away from a BYOC PaaS later isn't nearly as disruptive as migrating off a shared-tenant platform. The infrastructure stays put; only the management layer changes hands. That alone should lower how risky this feels going in, since the worst case is a lighter lift than anything Heroku ever offered its customers on the way out the door.