What is multitenancy? Architecture & secure multi-tenancy

Multitenancy is an architecture pattern where a single set of infrastructure, such as application code, databases, or compute resources, serves multiple customers at once. Each customer is a tenant, and each tenant's data and workloads stay logically or physically separated even though they share the same underlying resources.

Platform engineers and DevOps teams use multitenancy to scale a product to many customers without duplicating infrastructure for each one. This article covers how multi-tenant architecture works, the isolation patterns available, and what secure multi-tenancy requires in practice.

Multitenancy is an architecture pattern that lets a single set of resources, such as application code, a database, or infrastructure, serve multiple tenants at the same time. Tenants share the same physical resources but stay logically separated from each other.

A tenant can be a customer, team, or organization using a shared service. Tenants don't see each other's data, and one tenant's usage doesn't affect another tenant's performance. That separation is what allows a platform to scale without provisioning new infrastructure for every new customer.

Email hosting is a common example. Gmail runs on shared backend infrastructure used by millions of accounts, but each inbox is logically separated. Application logic keeps each tenant, in this case each inbox, isolated from every other tenant on the same system.

In cloud computing, multitenancy means running shared physical infrastructure to serve workloads for multiple customers. This applies to public cloud providers like AWS and Google Cloud, and to platforms that run on dedicated hardware.

SaaS and PaaS products are typically multitenant by design. Salesforce and Gmail serve many customers from the same codebase and infrastructure, separating tenant data at the software layer.

The same concept applies to containerized and IaaS environments. In Kubernetes, a namespace can represent a tenant boundary. Containers and serverless functions often share the same kernel, which introduces noisy neighbor effects and, in some threat models, side-channel risk between workloads. Runtimes like Kata Containers and gVisor address this by adding isolation below the container layer. See what are Kata Containers for how VM-level isolation works under Kubernetes.

A multi-tenant cloud architecture defines how an application, database, and infrastructure are structured to serve multiple tenants without leaking data or causing performance interference between them. Teams typically choose from four patterns, each with a different isolation and operational tradeoff.

Choosing between these patterns is a tradeoff between operational overhead and isolation. Shared instances and databases are simpler to operate at scale. Separate schemas and databases provide stronger isolation at the cost of managing more infrastructure.

Multitenancy provides four main benefits for teams scaling a shared platform:

• Cost savings: Tenants share compute, storage, and networking, so you're not paying for unused capacity in a dedicated environment per customer.
• Scalability: New tenants can be added without deploying a new stack for each one.
• Centralized updates: A single deployment ships updates and fixes to all tenants at once, removing the need for separate upgrade cycles.
• Better resource utilization: Shared infrastructure allows load to be balanced across tenants instead of sitting idle in dedicated environments.

Running multiple tenants on shared infrastructure introduces risks that single-tenant systems don't have to manage.

Multi-tenancy is implemented across three layers: the database, the application, and the infrastructure. Each layer needs its own isolation controls.

The application identifies which tenant is making a request, typically from a request header or authentication token, and uses that tenant ID to scope configuration and data access.

Containers and virtual machines separate tenant workloads at the infrastructure layer. Standard containers rely on Linux namespaces and cgroups, which share a kernel across workloads. For workloads that require stronger boundaries, such as untrusted or dynamic code, microVM runtimes like Kata Containers run each workload in a dedicated VM with its own kernel. See containers vs virtual machines for a full breakdown of that isolation tradeoff. In Kubernetes, namespaces separate tenant environments, and IAM policies control which users can access which tenant's resources.

Secure multi-tenancy is a multi-tenant architecture where tenant isolation is enforced by technical controls at the network, identity, and runtime layers, not only by application logic. Relying on application code alone to separate tenants leaves a single bug or misconfiguration as the only barrier between tenants.

Secure multi-tenancy typically combines:

• Identity and Access Management (IAM): restricts which users and services can access a given tenant's resources.
• Encryption: data encrypted at rest and in transit, so it stays protected even if underlying storage is compromised.
• Network isolation: tenants separated at the network level, preventing traffic from crossing tenant boundaries.
• Runtime isolation: containers, namespaces, and microVMs used to separate compute at the kernel or hardware level. See what is a microVM for how this works below the container layer.
• Monitoring and audit logging: continuous visibility into tenant activity to detect and respond to anomalies.

Northflank provides namespace isolation, RBAC, and runtime isolation for multi-tenant workloads running on Kubernetes.

Each tenant can run in a dedicated namespace with access restricted for linked Git accounts and services, so one tenant's environment doesn't overlap with another's. Network isolation is handled with Cilium and Kubernetes NetworkPolicies, which block cross-namespace and cross-project traffic. For service-to-service communication, Northflank's built-in service mesh enforces mutual TLS (mTLS) between tenants' services. See the documentation on restricting namespaces for configuration details.

For workload-level isolation, Northflank runs Kata Containers with Cloud Hypervisor as the primary microVM isolation path, giving each workload a dedicated kernel. Firecracker is applied for workloads suited to its minimal device model.

Where nested virtualization isn't available, Northflank falls back to gVisor, which isolates workloads by intercepting syscalls in user space rather than running a dedicated kernel. This combination reduces the attack surface for multi-tenant and untrusted workloads compared to standard container isolation alone. This isolation is available through Northflank Sandboxes for teams running untrusted or tenant-specific code. See Kata Containers vs gVisor for how the two approaches compare.

RBAC controls who can deploy services, manage secrets, or view activity logs across a multitenant setup, with roles assignable to users or groups. See the RBAC guide for role configuration.

Governance features add centralized visibility across tenants, including audit logs of activity across teams and projects, and controls for Git integrations and namespace restrictions. Northflank is SOC 2 Type 2 compliant, which gives teams in regulated environments a documented basis for the platform-level controls behind tenant isolation. See the collaboration and governance docs for details.

Multitenancy means a single platform or environment serves multiple independent tenants, sharing the same underlying resources while keeping tenant data and workloads isolated from each other.

Secure multi-tenancy is multitenancy where isolation is enforced through IAM, encryption, network segmentation, and runtime isolation, rather than relying on application logic alone to separate tenants.

SaaS platforms like Salesforce and Gmail are multi-tenant examples, serving many customers from shared infrastructure while keeping each customer's data separate. Kubernetes namespaces are a multi-tenant pattern at the infrastructure level.

The main risks are resource contention between tenants and data leakage from insufficient isolation. Namespace isolation, RBAC, and runtime isolation reduce both risks.

Single-tenant systems dedicate a full environment to one customer, giving stronger default isolation at higher cost. Multi-tenant systems share infrastructure across customers, reducing cost but requiring explicit isolation controls.

Combine Kubernetes namespaces for tenant boundaries, NetworkPolicies for network isolation, RBAC for access control, and a stronger container runtime such as Kata Containers or gVisor for workloads that need kernel-level separation.

Multitenancy reduces infrastructure cost and operational overhead by sharing resources across customers, but secure multi-tenancy requires isolation controls at the database, application, and infrastructure layers.

To continue researching this topic:

• Multi-tenant cloud deployment covers deployment patterns for running multi-tenant workloads across cloud providers.
• What is a sandbox environment explains isolated execution environments, a related concept used for untrusted or tenant-specific workloads.
• Your containers aren't isolated breaks down container escape risks and where microVM isolation closes the gap.
• Northflank's documentation covers namespace and RBAC configuration in more depth.
• Sign up to configure tenant isolation on Northflank directly.