Ask what risk they want to remove before you quote anything. Buyers asking for single-tenant hosting usually worry about data mixing, noisy neighbours, residency or regulator expectations. Many of those can be addressed with documented logical separation, encryption choices and evidence. Offer dedicated hosting only if the concern truly needs it.
Definitions
- Multi-tenant. Customers share application and infrastructure, separated logically by tenant identifiers, access controls and sometimes separate keys.
- Single-tenant. A customer gets a dedicated instance, often with its own database and compute, though the vendor still operates it.
- Customer-hosted. The software runs in the customer's own cloud account or data center.
These are points on a spectrum, not three boxes. Many vendors offer hybrids such as shared compute with dedicated databases.
Find the concern behind the request
| Stated request | Possible underlying concern | Options to discuss |
|---|---|---|
| "We need our own instance" | Data mixing between customers | Evidence of tenant isolation tests, row level controls, per tenant encryption keys |
| "We need our own instance" | Performance interference | Resource limits, rate limits, a performance commitment |
| "Data must stay in one country" | Residency expectations | Regional deployment, documented backup locations |
| "Our regulator expects dedicated" | Supervisory guidance | Ask which text, then compare it with what you can offer |
| "We want to control the keys" | Key custody | Customer-managed key option |
The post on do enterprise buyers need per-tenant encryption keys goes deeper on the key question.
Show your isolation evidence
If you are multi-tenant, be ready to explain concretely how one customer cannot reach another's data: where tenant identity is checked, how queries are scoped, how background jobs carry tenant context, and how you test for cross-tenant access. See how to answer how is customer data separated in multi-tenant SaaS and threat model a multi-tenant SaaS tenant isolation.
Independent testing that targets tenant boundaries is persuasive. Include it in scope; see the pen test scope checklist.
If you do offer dedicated hosting
Think about operations before you say yes.
- Patching. Each instance must be updated. Will you roll them on one schedule, or does the customer control timing?
- Monitoring and logging. Each instance needs the same coverage as the shared service.
- Configuration drift. Dedicated instances tend to diverge. Automate builds from one definition.
- Support access. Define who on your staff can reach the instance and how it is logged.
- Exit. Decide how the instance is deleted and confirmed at termination.
A dedicated instance that is patched late becomes a weaker setup than the shared service it replaced. That outcome should be on the table in the conversation.
Be careful with the word "private"
Do not describe a dedicated database as a "private cloud" unless it meets what the buyer means by that. Say exactly what is dedicated: database, compute, network, keys, or all of them.
Decide as a policy
Write down when you will offer dedicated options, what minimum commitments apply, and who approves. Otherwise each deal invents a one-off setup that your engineers must maintain forever. For the buyer's point of view on the same choice, see single-tenant or multi-tenant hosting: which to buy.
Safeguard's asset discovery can help you keep track of every environment you run, which becomes harder with each dedicated instance.
Quick check
Is single-tenant always more secure?
No. It reduces some risks, such as cross-tenant access, but adds operational ones, such as inconsistent patching. Security depends on how it is run.
Can we offer customer-managed keys without single-tenant hosting?
Often yes, if your design supports per tenant keys. Check your architecture before promising.
Last reviewed: 19 October 2026.
