Single-Tenant vs Multi-Tenant: What Your Crisis Platform's Architecture Decides Before the Crisis Starts

Multi-tenant SaaS is cheaper, faster to update and more efficient to run. For most software, that settles the argument. For the platform you will depend on when your main systems have been compromised, it does not.

The question for a crisis communications or incident response platform is not "which is better?" It is "what happens to me when something goes wrong with someone else?"

Tenancy model (single-tenant or multi-tenant) is the single biggest determinant of that answer, and it is decided long before any incident begins.

This article sets out the trade-offs honestly, including where multi-tenant genuinely wins. YUDU Sentinel runs single-tenant by design, so we have a view. You should test it against the questions at the end, whichever vendor you choose.

What the terms actually mean

Multi-tenant means many customers share one running application, one set of servers and usually one database. Each customer's data is separated logically, typically by a tenant ID on every record and access rules in the code. The separation is only as strong as that code and its configuration.

Single-tenant (VPC) means each customer gets their own instance of the application, running in its own isolated network (a Virtual Private Cloud) with its own servers and database. The separation is enforced by the cloud provider's network and infrastructure boundaries, not by application logic.

In practice this is a spectrum, not a binary. Some vendors share the application tier but give each customer a separate database. Others call themselves single-tenant while still relying on a shared login service, shared admin console or shared deployment pipeline. Those shared components are where the risk hides, so ask about each one.

Sentinel sits at the far end of the spectrum. Each client runs a fully independent instance on AWS, with its own operating system, not connected to or dependent on any central Sentinel system.

Where multi-tenant genuinely wins

Cost. Shared infrastructure is cheaper per customer. One database cluster, one set of application servers and one monitoring stack are spread across hundreds of customers. Single-tenant carries a fixed infrastructure floor per customer, whether that customer is busy or idle. That cost is real and it shows up in the price.

Capacity efficiency. Customers peak at different times, so a shared pool can be sized for the combined average rather than every individual peak. A single-tenant instance must carry enough headroom for its own worst day, which means it sits largely idle most of the time. For a crisis platform that is arguably the point, but it is still paid-for idle capacity.

Speed and uniformity of updates. One deployment updates every customer at once. Security patches, bug fixes and new features reach everyone in the same hour. With single-tenant, every instance has to be updated. The gap is real, but automation narrows it to hours rather than days (see patching below).

Common code. Everyone runs the same version, so the vendor tests one configuration and support staff troubleshoot one known state. Single-tenant vendors must enforce common code deliberately. Per-customer code forks are a trap: every fork multiplies testing, makes updates error-prone and erodes quality and stability as the estate grows. At YUDU Sentinel this is a golden rule. The code is never forked; client-specific needs are met by switching features on or off in configuration, so every instance runs the same tested codebase.

Onboarding speed. Adding a tenant to a shared platform can take minutes: create an account, configure, go. Provisioning a dedicated environment takes longer, though with infrastructure-as-code it should be hours, not weeks. Ask any single-tenant vendor what their provisioning time actually is.

Where single-tenant wins

Blast radius. This is the decisive difference. In a multi-tenant platform, one compromise of the shared application, database or credentials can expose every customer at once. A cross-tenant bug, a misconfigured access rule or a stolen admin key does not respect logical boundaries. In a single-tenant model, an attacker who breaches one instance has breached one customer. Moving laterally to the next requires breaking through a separate network, separate servers and separate credentials.

Impact of a successful attack: the CodeRED case. In November 2025, the INC Ransom group breached OnSolve's CodeRED emergency notification platform, used by US state and local governments, police and fire agencies. Attackers gained access on 1 November and encrypted systems on 10 November. Crisis24 had to decommission the entire legacy environment, which disrupted alerting for every customer simultaneously. Personal data including names, addresses, phone numbers and account passwords was stolen. (BleepingComputer, Malwarebytes)

The lesson is not that one vendor was careless. It is that a shared platform turns one incident into everyone's incident, at exactly the moment those customers needed the platform to work.

Ability to manage and restore. Restoring a shared platform means restoring everyone together, to a single point in time chosen by the vendor. CodeRED's rebuild relied on a backup dated 31 March 2025, roughly seven months before the attack, so recent accounts and data were lost (BleepingComputer).

With single-tenant, each instance can be isolated, investigated and restored on its own, to its own recovery point, without touching any other customer.

Single-tenancy also changes the recovery playbook. When a Sentinel client instance is compromised, the standard response is not to hunt for and remove the malware in place. The compromised servers are quarantined, not destroyed, so forensic examination can proceed independently. Meanwhile, fresh servers are spun up in minutes and the database restored onto them, so service resumes without waiting for the investigation to finish.

This matters because cleaning in place often fails. Attackers leave backdoors, dormant malware and stolen credentials behind, and systems declared clean have had to be taken down a second time. Rebuilding is not a cure-all either. In one published case, a company hit by Royal ransomware on 23 November 2022 rebuilt its AWS environment from backup; within three weeks the ransomware returned, and two domain admin accounts were found to be compromised (ThreatDown). A rebuild is only clean if the restore point predates the compromise and every credential is rotated.

Data sovereignty. A dedicated instance can be placed in a specific region and stays there. Multi-tenant platforms often run in a handful of regions and may replicate, back up or process data elsewhere. Sentinel instances can be hosted in any AWS region; they currently run in the UK, Ireland (EU), US and Singapore, with Germany available for in-country residency.

Control over update timing. Simultaneous updates are an advantage until a bad release breaks everyone at once. Cloudflare's global outage on 18 November 2025 was caused by a malformed internal configuration file that propagated across its entire network within minutes (CyberInsider). Single-tenant allows staged rollouts that contain that risk. Sentinel releases move in phases: first to staging, where they are tested with both automated tools and human checks; then to YUDU-owned live environments such as demo sites for wider testing; then to a selection of core clients; and only then across the estate. Clients are advised ahead of each release and can schedule or defer updates to avoid clashes with planned exercises or live incidents.

Out-of-band independence. A crisis platform exists to work when your primary systems do not. If it shares identity, infrastructure or a provider with the systems it is meant to back up, it can fail alongside them. A dedicated instance outside your main environment removes one more shared dependency.

Availability zones, mirroring and the database

Single-tenant is not automatically more available. One instance in one data centre is a single point of failure. Isolation protects you from other customers' problems; it does nothing for a power or network failure in your own zone. Availability has to be designed in separately.

Multiple availability zones. An AWS region contains several physically separate availability zones. Running across two or more means losing one data centre does not take the service down. Large multi-tenant platforms usually do this well, because the cost is shared across all customers. In a single-tenant model, multi-AZ is paid for per customer, so some vendors quietly skip it. Ask.

Mirrored application servers. Running two or more application servers behind a load balancer, in different zones, lets one fail or be patched without an outage. The same principle applies in both models. The difference is again who pays and whether it is standard or an upgrade.

Database implications. This is where the models diverge most.

• In a shared database, restoring one customer to an earlier point is hard. The vendor must extract that tenant's rows from a backup without disturbing anyone else, which is slow and error-prone. Restoring the whole database rolls back every customer.
• Schema changes and database upgrades in a shared database hit every customer at once, and so does a corrupted table or runaway query.
• With a dedicated database, point-in-time recovery for one customer is a routine operation. It can be tested per customer, and a restore affects nobody else.

Backups must be isolated too. Ransomware operators target backups first. A dedicated instance whose backups sit in the same account, with the same credentials, is only partly protected. Backups should be immutable and held in a separate account or vault. CodeRED's seven-month-old recovery point shows what happens when backups are not current and protected.

How Sentinel is configured. Sentinel's standard configuration runs across multiple availability zones, with load balancers, a minimum of two mirrored application servers, and synchronous database replication with automatic, immediate failover. That gives Sentinel two separate recovery layers, and the honest answer to "what is your RPO?" depends on which layer is doing the work.

Replication protects against hardware and infrastructure failure, but it also copies bad changes. If data is deleted, corrupted or encrypted, the replica receives the same damage at the same moment, so recovery has to come from backup. Sentinel can roll a client's database back to any point in the previous 24 hours, keeping data loss to a minimum, with daily snapshots retained for 30 days providing older restore points. All backups are immutable and held separately from production, so an attacker who reaches the live system cannot alter or delete them. Compare that with CodeRED, whose most recent usable backup was seven months old.

One caveat applies to every vendor: the restore point must predate the compromise. Attackers often sit undetected before acting; in the CodeRED attack, nine days passed between initial access and encryption. Detection speed matters as much as backup frequency.

Support and security operations

Support. Multi-tenant support is efficient because everyone is on the same version and the same infrastructure. But it is generic: during a platform-wide outage you are one ticket among thousands, and every customer's crisis lands on the same support team at once. Single-tenant support can look at your instance specifically, inspect its logs and act on it without risk to others. The trade-off is that the vendor must run more environments with the same staff, which only works with strong automation.

Isolation also changes the arithmetic of a major incident. Because each instance stands alone, the probability of many clients being hit at the same moment is very low, so the support team can concentrate its resources on the one client affected. When a shared platform goes down, hundreds or thousands of customers lose service together, and no vendor can scale support fast enough to serve them all.

Patching overhead is the honest weakness of single-tenant. Every instance has its own operating system and software stack to patch. If a critical vulnerability is announced, a multi-tenant vendor patches once. A single-tenant vendor must patch every instance, and any instance left behind is exposed. Automation closes most of that gap. When PHP 8.4.27 was released on 21 October 2026 to fix two critical vulnerabilities allowing unauthenticated remote code execution (PHP release notes), Sentinel's benchmark was two hours from release to 100 servers updated, and parallel processing can shorten that further for very large estates. Single-tenancy also allows targeted patching: when one client needs a fix urgently, their instance can be patched and tested with them, at far lower risk than changing a platform every customer shares. Buyers should still ask any single-tenant vendor for patch SLAs and evidence rather than assume.

Monitoring and detection. A shared platform gives the vendor one large dataset in which to spot anomalies. Dedicated instances need monitoring deployed to each, with alerts aggregated centrally. Done well, per-instance monitoring makes an intrusion easier to attribute and contain. Done badly, it leaves blind spots.

Audit and evidence. Per-instance logs belong to one customer, so they can be handed over for an investigation or regulator without redacting other customers' data. Sentinel provides a full, exportable audit log with tamper-evident timestamping on each instance.

Other factors worth weighing

Target value. A shared platform holding hundreds of organisations' contact lists and crisis plans is a far more attractive prize than any single instance. Attackers invest in proportion to the payoff.

Noisy neighbours. In a shared platform, another customer's major incident can consume capacity just when you need it. A regional event affecting many customers at once is precisely when a crisis platform is under most load. Dedicated capacity is not drawn down by anyone else.

Encryption key separation. Per-customer encryption keys limit what a single stolen key can unlock. Multi-tenant platforms can offer this, but it is often an enterprise add-on. In a dedicated instance it is the natural default.

Vendor-side shared components. Single-tenant isolation is only as strong as the vendor's own estate. A shared deployment pipeline, a central admin console or engineers' privileged access can still link instances together. Ask how vendor access is controlled, logged and segmented.

Shared third-party services. Neither model escapes shared upstream providers. SMS, voice and video are typically delivered through specialist carriers and platforms used by many vendors. Ask every vendor which third parties carry your messages, what data they hold and where.

Exit and portability. Leaving a dedicated instance usually means a clean export of one self-contained dataset. Leaving a shared platform means trusting the vendor to extract and delete your records from a common database.

Testing and assurance. A dedicated instance can be penetration-tested by the customer or their assessor without risk to others. Most multi-tenant vendors forbid customer-led testing of shared infrastructure and offer only their own reports.

At a glance

Questions to ask any vendor

1. If another customer is breached, what is the path from their environment to mine

2. Which components are shared: login, admin console, database, deployment pipeline, backups?

3. Can you restore my data alone, to a point I choose, and how long does it take?

4. How often are backups taken, where are they held, and are they immutable?

5. Is my service deployed across more than one availability zone as standard?

6. Which region will my data live in, and does any of it leave that region?

7. How quickly are critical patches applied to every customer, and how do you prove it

8. Can I defer an update during a live incident or audit?

9. Which third parties carry my messages, and what data do they keep?

10. May my own assessor penetration-test the service?

The bottom line

If the software you are buying is a productivity tool, multi-tenant is usually the right answer. It is cheaper, it updates faster, and a short outage is an inconvenience.

An out-of-band communications platform is different. You buy it for the day everything else has failed, and on that day the questions that matter are blast radius, isolation and restore. Those are the questions single-tenant architecture answers best. The extra cost buys separation from everyone else's bad day.

The CodeRED attack showed the alternative: one breach, every customer offline, months of data gone. Whichever vendor you choose, make them answer the ten questions above in writing.