Single-tenant vs multi-tenant PaaS: infrastructure-level changes for regulated industries

Regulated teams are often handed "single-tenant" as a requirement, usually from procurement, an auditor, or a prospect's security team, with no explanation of what it is for. It is an expensive constraint to accept at face value.

The tenancy label is rarely what anyone actually needs. What an auditor checks is whether you can prove a set of guarantees: that your data is isolated, that a noisy neighbor cannot starve your workload, that data sits where regulation says it must, that you can produce evidence of your controls, and that a failure in one place stays there. A few of those guarantees genuinely require dedicated infrastructure. Most do not.

Teams that accept it unexamined tend to buy the most expensive version of it and still not satisfy the auditor, because the questions that mattered were about isolation and evidence rather than hardware. The more useful question is which guarantees you have to prove, and where on the shared-to-dedicated spectrum each workload needs to sit. This piece works through both, at the infrastructure level.

What single-tenant and multi-tenant mean at the infrastructure level

A tenancy model describes how one customer's workload is separated from another's. 

1. Single-tenant gives each customer a dedicated stack: their own compute, often their own database, sometimes their own hardware. Nothing is shared with another customer. The isolation story is simple to explain, and it is also the most expensive and the slowest to provision.
2. Multi-tenant runs many customers on shared infrastructure, separated by software rather than by dedicated hardware. It is efficient and fast to provision, and its safety depends on how well the provider enforces separation between tenants. Plenty of compliant, regulated systems run this way.

Both single-tenant and multi-tenant describe the two ends of a spectrum, and most platforms today sit between them rather than at either end. That middle ground is the third option, and it is the one most often left out of the conversation.

3. Strict per-project isolation on shared cloud is where most modern platform-as-a-service sits, and it is the point people miss. Each project runs in its own isolated environment on top of shared cloud infrastructure, with a dedicated-cluster option for workloads that need physically separated resources. It offers most of the isolation benefit of single-tenant without applying single-tenant cost to every workload. 

Naming all three matters, because a requirement written as "single-tenant" is often met by the third option at a fraction of the cost.

Tradeoffs: cost, operations, and speed across the spectrum

Before working out which one you need, it helps to know what each costs you, because the differences are large and they are not only financial.

• Full single-tenant gives the strongest and simplest isolation story, which is sometimes contractually required. It also carries the highest infrastructure cost, the most operational overhead, and the slowest provisioning, because every customer's stack is stood up and maintained separately.
• Multi-tenant is the most efficient and the fastest to provision, and it asks you to trust and verify the provider's separation between tenants. For workloads whose regulatory requirements are met by strong logical separation, this is often the sensible choice.
• Strict isolation with a dedicated option where needed aims at the middle: most of the isolation benefit as the default, with dedicated resources reserved for the workloads that truly require physical separation. It keeps cost and operational load proportional to the actual requirement rather than applying the most expensive model to everything.

The mistake to avoid is paying a single-tenant cost across an entire estate to satisfy a requirement that applies to one workload.

Why regulated industries ask for single-tenant

"We need single-tenant" is usually shorthand, handed down from a security team, a procurement checklist, or an auditor. Underneath it sits a set of real requirements, and each is a guarantee you prove rather than a hosting model you buy.

• Data isolation. One customer must never reach another's data. This is the core worry, and it is satisfied by verifiable isolation, which dedicated hardware is one way, but not the only way, to provide.
• No noisy-neighbor contention. A regulated workload cannot have its performance degraded by another tenant's traffic spike. This calls for dedicated or guaranteed resources for the workloads that need them, not necessarily a fully dedicated stack for everything you run.
• Data residency. Regulation often dictates the country or region where data physically lives. This is about where you can place a workload, which is a property of the platform's cloud coverage, not of tenancy.
• Right to audit and evidence of controls. You must be able to show what your controls are, when they changed, and who approved the change. This is about the evidence the platform produces, and it is independent of the tenancy model.
• Blast-radius containment. An incident in one place must not spread. This is about isolation and segmentation, which strict per-project isolation provides without a dedicated stack per customer.

Only two of those five actually need dedicated infrastructure: guaranteed resources, and physical separation where a contract specifically demands it. The other three can be met on strictly isolated shared infrastructure.

Why the answer sits at the infrastructure level

Look back at that list of requirements and notice what none of them mention: how many customers share a machine. Data isolation is enforced by network segmentation and access control. Residency is decided by which region a workload runs in. Evidence of controls comes from what the platform records when you deploy. Blast-radius containment is a segmentation property. Every one of these is an infrastructure control, and a tenancy model is at best a crude proxy for having them.

That is why "single-tenant or multi-tenant?" is such an unhelpful place to start. It asks about the packaging rather than the contents. Two platforms can both call themselves single-tenant and differ enormously in how they segment networks, what they log, and which regions they can reach. Two others can both be multi-tenant and be nothing alike on the same measures.

So the decision moves down a layer. Instead of picking a tenancy model and hoping the controls follow, you work out which controls you need to prove, verify that a platform provides them, and let the tenancy model be whatever it happens to be. The rest of this piece is about that layer: the questions worth asking, and the changes worth making.

The infrastructure-level questions to ask a PaaS

These are the questions worth putting to any platform under consideration. Each one targets a control rather than a label, and the answers are usually more revealing than anything on a feature page.

How is tenant data isolated?

Ask for the mechanism, not the marketing word. Is separation enforced by dedicated infrastructure, by network segmentation, by per-project isolation, or by some combination? A clear, documented isolation model matters more than the label attached to it.

Are compute and data resources dedicated or shared, and can you get dedicated when required?

For most workloads, guaranteed resources on isolated infrastructure are enough. For the ones that genuinely need physically separated compute, the question is whether the platform offers a dedicated option without forcing you onto a different way of working.

Where does data physically live?

Confirm which regions and which cloud providers are available, and whether you can place a workload where a residency rule requires. A single-provider platform limits your answer here before you begin.

Does compliance cover every environment or only production?

This is where many teams get caught. If certifications and controls apply only to production, then your staging and preview environments, which often hold copies of real data, sit outside the compliant boundary. Ask whether compliance holds across all environments.

What audit evidence can the platform produce, and how?

The best answer is that evidence is generated automatically as a byproduct of how you deploy, rather than assembled by hand before each audit. Ask whether change history, access logs, and deployment records exist by default and cover every environment.

Who is responsible for what?

Every platform splits responsibility with the customer. Ask for the shared-responsibility model in writing: which infrastructure controls the platform owns, and which application-level controls remain yours. Clarity here prevents both duplicated effort and dangerous gaps.

The infrastructure-level changes regulated teams need

Knowing what to ask is half of it. The other half is what you change on your side, because the controls below make compliance a property of how you deploy rather than something you assemble before each audit. These are the changes the title of this piece points at.

• Environments recreated identically from a definition. The most common cause of audit findings is drift: a staging server configured differently from production, a port opened for a test and never closed. When every environment is built from the same version-controlled definition, drift stops being possible, and "prove staging matches production" becomes trivial. 
• Guardrails enforced by the platform. Security rules that live in a document get bypassed. Rules encoded into the platform cannot be. A database with no public route defined, for example, cannot be accidentally exposed. This gives developers autonomy inside safe boundaries and removes whole classes of risk by design.
• Audit evidence generated automatically. Change history, access logs, and deployment records that exist by default turn evidence collection from a project into a query. The audit conversation shifts from assembling screenshots to pointing at records that were already there. 
• A clear shared-responsibility split. Knowing exactly which controls the platform owns and which remain yours lets you inherit the infrastructure-level controls and focus your effort on the application layer, where your specific risk actually lives.

None of these four changes is a tenancy decision. Together they deliver most of what "single-tenant" was being asked to guarantee.

How Upsun handles isolation and compliance for regulated teams

Upsun sits at more than one point on the spectrum on purpose, which is what lets it meet a regulated requirement without overbuilding.

• Strict project isolation by default. Each project runs in its own sealed environment. Nothing gets in except on three approved ports, and services cannot talk to each other unless you explicitly connect them. Technically, that isolation is enforced by namespaces, seccomp, and cgroups, which is the same mechanism auditors expect to see documented.
• Multi-cloud residency. Upsun deploys to AWS, GCP, Azure, IBM Cloud, or OVHcloud from one workflow, so a workload can be placed where a residency rule or contract requires while the deployment and security configuration stay the same across providers. 
• Compliance across every environment. Upsun holds ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, and TX-RAMP, and applies its controls across all environments rather than production alone, which matters because preview and staging environments often hold copies of sensitive data. 
• A defined shared-responsibility model. Upsun owns the infrastructure layers, including operating system patching, network isolation and segmentation, container hardening, physical security, and platform availability. The customer owns the application layer: application logic, data classification, and access decisions. 
• Audit evidence as a byproduct of how you deploy. Because the whole environment stack is defined in a version-controlled .upsun/config.yaml and every deployment and configuration change is logged, change history and access records exist across every environment by default. Evidence collection becomes a query against records that were already generated, not a project run before each audit. 

Upsun is not a single-tenant platform and does not need to be. It delivers strict isolation as the default, dedicated infrastructure where a workload requires it, residency control, compliance across environments, and automatic evidence, which is the set of guarantees a "single-tenant" requirement is usually reaching for.

You can map its controls to your own requirements through the compliance and governance solution and the Trust Center.

Which model fits which situation

• Choose full single-tenant: If a specific contract, regulator, or hardware requirement genuinely mandates a dedicated stack per customer, and the cost and operational overhead are acceptable and expected.
• Multi-tenancy is fine: If your regulatory requirements are met by strong, verifiable logical separation, and you value efficiency and fast provisioning. Many compliant systems run this way.
• Strict isolation with a dedicated option where needed fits the largest real-world case: You need provable isolation, residency control, and audit evidence across every environment, with dedicated infrastructure reserved for the specific workloads that require it. This is where most regulated teams land once the requirement is reframed away from the tenancy label.

Frequently asked questions

Is multi-tenant hosting safe for regulated data?

It can be. Many compliant, regulated systems run on multi-tenant infrastructure. Safety depends on verifiable isolation and evidence of controls, not on the tenancy label. The question to ask is how separation is enforced and what evidence the platform can produce, rather than whether the platform is multi-tenant.

Does PCI DSS or HIPAA require single-tenant hosting?

No. Neither PCI DSS nor HIPAA mandates single-tenant infrastructure. Both require specific controls around isolation, access, and evidence, which can be met on strictly isolated infrastructure. Confirm any specific control with your assessor rather than assuming a tenancy model is required. 

What is the difference between single-tenant and dedicated hosting?

They overlap but are not identical. Single-tenant describes separation at the customer level; dedicated hosting describes physically separated resources. A platform can offer dedicated resources for a workload, such as a dedicated cluster, without running a fully separate stack for every part of a customer's estate.

Can you get data residency without single-tenancy?

Yes. Data residency is about which region and provider a workload runs in, which is a property of the platform's cloud coverage rather than its tenancy model. A multi-cloud platform lets you place a workload in a required region without a dedicated stack.

Is Upsun single-tenant or multi-tenant?

Neither label captures it. Upsun runs each project in strict isolation by default on shared cloud infrastructure, and offers PCI-certified Dedicated Clusters for workloads that need physically separated resources. The practical point is that it delivers the isolation, residency, and compliance guarantees a regulated team needs at the right point on the spectrum for each workload.