When it comes to multi-tenancy isolation, most platforms only support one approach, and you have to make it work for every customer. Usually that means either all tenants share the same infrastructure and rely on the application to keep them apart, or every customer gets a separate stack that your ops team has to deploy, patch, and monitor on its own.
Both approaches work. The trouble is that they're rigid. Tenants vary in how much isolation they need and in what they're worth to you, so one model applied to all of them will overprotect some and underprotect others, and the cost of running each one won't match its value.
That rigidity comes from the tooling, and tooling can change. On Cycle, you decide where the border between tenants goes, and you can put it somewhere different for each customer: shared, network segregated, or fully dedicated hardware, all from one control plane.
Treat multi-tenancy isolation as a placement decision
Multi-tenancy gets argued about like theology: shared versus dedicated, pooled versus siloed. We think it's simpler than that. For each tenant, the question is just where the border goes. A few things should drive the answer:
- Compliance and data residency. Regulations like GDPR and HIPAA, along with a customer's own security policies, can dictate where a tenant's data is stored and what else is allowed to run alongside it. When a tenant's data has to stay in a specific region or apart from other customers' workloads, that requirement sets the minimum level of isolation before anything else comes into play. Customers’ security reviews will look at your platform vendor as well, which is one reason Cycle achieved SOC 2 Type 1.
- Contract terms. Enterprise agreements often spell out how a customer's workloads must be hosted, and "dedicated infrastructure" shows up in them a lot. Once that language is signed, it's a hard requirement, so it pays to know which of your tiers can actually deliver it before sales promises it.
- Blast radius. Traffic spikes, runaway processes, and bad deploys happen. The more a tenant shares with others, the more likely its problems become their problems too. Tenants with strict uptime commitments, or ones whose workloads are unpredictable, usually earn a tighter border.
- Cost per tenant. Shared resources spread costs across many tenants, while dedicated servers are paid for by one. Matching each tenant's isolation to what they pay keeps margins healthy on your lower tiers and still gives premium customers the separation they're paying for.
- Ops capacity. Every boundary you add is one more thing to monitor, patch, and troubleshoot. If each one means extra manual work, isolation turns into a staffing problem fast. The more of that work your platform takes on, the more freely you can add borders where tenants need them.
Cycle gives you three places to draw that line: shared (tenants live together in one environment), segregated (each tenant gets its own environment and network), and dedicated (each tenant gets its own cluster, and its own servers). And you pick the tier for each tenant individually.
Two building blocks: clusters and environments
All three tiers come from two primitives.
A cluster is a logical group of servers, and it works like a guardrail. A server belongs to exactly one cluster, and servers in different clusters can't connect directly unless you deliberately set them up to talk over the public internet. Being in the same cluster doesn't open any links on its own; it just means those servers might need to communicate.
An environment is the closest thing to a VPC. Each one is tied to a single cluster, and a cluster can host as many environments as you like. Inside an environment you can run any Linux container, full VMs, and standalone functions side by side.
There's no special multi-tenant mode and no isolation add-on to buy. Where you place tenants relative to clusters and environments is the isolation model.
Tier 1: Shared tenants in one environment
The simplest option is no platform-level border at all. Tenants run as workloads in a single environment, sharing its network, services, and servers. It's the right fit for internal teams, free tiers, trials, and products with thousands of small tenants: lowest overhead, densest packing, nothing duplicated.
The tradeoff is that workloads in an environment share a flat network, so your application (auth, data model, code) has to keep tenants apart. Cycle isolates the environment from the outside world, but it won't referee between tenants inside it. If your app already enforces that separation, this tier is cheap and boring in the best way. If a single misconfiguration exposing one customer's data to another would be a serious problem for your business, one of the next two tiers is a better fit.
Tier 2: An environment per tenant
This is where most B2B products land. Each tenant gets its own environment, and even when those environments share the same servers in the same cluster, they can't see each other.
Every environment gets its own flat L3 network with environment-specific encryption keys, so one tenant's traffic is unreadable to every other, even on the same node. That network spans every provider you've connected, with no per-app network config. Cycle also only establishes links between nodes when workload placement requires them, which keeps machines lean and the attack surface small.
Each environment also runs its own load balancer, scheduler, discovery service, gateway, and VPN on your servers, so every tenant is its own failure domain. Traffic between tenants is off by default. When you need a path, say to a shared auth service, you open one deliberately with a software-defined network connection. Teams that have built this kind of separation by hand with a custom VPN mesh get the same result here without having to build or maintain it themselves.
Tier 3: A cluster per tenant
Sometimes a separate network isn't enough and the conversation turns to hardware: regulated industries, strict data residency, contracts with dedicated infrastructure written in, or a CISO who has declared "no shared metal."
For those tenants, give them their own cluster. Since a server belongs to exactly one cluster and clusters can't connect directly, the border becomes physical as well as logical. Different tenant, different servers, with no direct path between them.
Nothing is lost on the way up. Inside that cluster the tenant still gets the full environment model, with its own network, keys, and services, and can run several environments (production and staging, say) on hardware nobody else touches. It's the same Cycle, deployed and operated the same way.
One control plane covers it all
What makes this setup practical is that moving a border doesn't mean changing tools. Shared tenants, segregated environments, and dedicated clusters all show up in the same place: servers and clusters under infrastructure, environments on their own page, one pane of glass whether you run one shared environment or a long list of tenants across several clusters.
That matters because most of what isolation really costs comes from the second platform, the second set of runbooks, and the second on-call rotation you inherit the moment a premium customer wants their own stack. On Cycle, you keep running the same platform with the same tools, and you simply decide where each tenant's border sits.
Updates stay in your hands too. Roll changes across tenants in parallel or one at a time, with several ways to automate it. For example, you can patch low-risk tenants first, confirm everything is running smoothly, and then roll the update out to tenants with stricter contractual or compliance requirements.
Mixing tiers on one platform
Real products rarely have one kind of tenant. A typical SaaS setup on Cycle might look like this:
- Free and trial tenants share a single environment. Cheap, dense, low risk.
- Standard customers each get their own environment on a shared cluster, encrypted and segregated at little extra cost.
- Shared services like auth or billing live in their own environment, connected to tenant environments through SDN connections you opened on purpose.
- A regulated enterprise customer gets a dedicated cluster, with environments inside it.
All of these tenants run on the same platform and are managed by the same team from a single control plane, so supporting a large enterprise customer doesn't require building or operating a separate platform.
Isolation can also change as a tenant does. A trial account that gets serious can migrate to its own environment, and a customer who signs a bigger contract can migrate onto dedicated hardware. Each move is a deliberate migration, but every tier runs on the same platform, so your architecture can follow the business as it grows.
Draw the line where your tenants need it
Multi-tenancy isolation doesn't have to be a decision you make once and live with forever. With clusters and environments, you set the border tenant by tenant, from fully shared to fully dedicated hardware, and run it all from one control plane with very little operational overhead.
Want to talk through how your tenants break down? Reach out, tell us what you're running, and we'll help you map it to the right borders. We're always happy to demo it live.