Technical enablement · 06

Deployment models

{{product.name}} can typically be consumed in two ways: as a managed multi-tenant service run by the product team, or as a dedicated deployment in a client-controlled environment. This page helps you choose, and lists what each model involves. Delete a model if the product does not support it.

⚠

Commercial, legal and data-residency questions (pricing, liability, hosting location, subprocessors) are not decided on this page. Involve Legal, Compliance and the Data Privacy Officer early, and treat the technical options below as input to those conversations.

The two models at a glance

Figure 1 — The two deployment models. Adjust the boxes if {{product.name}} also supports a hybrid or single-tenant-hosted variant.

Comparison

Dimension	A · Managed multi-tenant	B · Dedicated / client-hosted
Time to first value	[Replace: e.g. days; tenant provisioned]	[Replace: e.g. weeks; infrastructure build]
Data location & control	Hosted by the product team in [Replace: region].	In the client's environment and region.
Tenant isolation	Logical (application and data layer).	Physical or account-level.
Upgrades	Continuous, scheduled by the product team.	Agreed windows; client approves.
Customisation	Configuration within the shared model.	[Replace: wider, e.g. custom integrations]
Operations	Product team runs and monitors.	Shared or client-run; see operations.
Cost profile	Subscription; shared infrastructure. [Replace]	Client pays infrastructure plus support. [Replace]
Security review burden	One platform assessment, reused.	Per-client review of the deployed estate.

Model A — managed multi-tenant

The client receives a tenant on a platform the product team runs. [Replace: one paragraph on what is shared, what is per-tenant, and the support model.]

Onboarding steps

Request and approve

Raise a request via {{links.bookSession}} or the internal intake route. [Replace: approvals, security questionnaire.]
Provision the tenant

A platform admin creates the tenant and first admin (see tenancy and access).
Configure and load data

Follow the implementation flow from step 2.

ⓘ

Record any capability that is not available in the shared model, for example features that need dedicated infrastructure or client-specific integrations.

Model B — dedicated / client-hosted

The product is deployed into an environment the client controls. [Replace: supported targets, such as a client cloud subscription, a private cloud, or on-premises Kubernetes.]

Prerequisites

A target environment with [Replace: minimum capacity, regions, network access].
Identity integration agreed with the client's IT security team.
Outbound access to any third-party services listed in Integrations, or approved substitutes.
A named client technical owner and an agreed change window.

1 · Describe the deployment

Capture the choices that differ per client in one reviewed file, and treat it as the single source for provisioning.

deployment manifest (example structure)

client: [client-code]
environment: production
region: [region]
components:
  api-gateway:   { enabled: true,  replicas: 2 }
  core-service:  { enabled: true,  replicas: 2 }
  ai-service:    { enabled: false }            # optional component
integrations:
  identity:      [provider-name]
  ai-provider:   [provider-name]
secrets:
  store: [vault-name]                          # references only, never values

2 · Provision infrastructure

Use infrastructure-as-code so environments are reproducible and reviewable.

provision (example)

cd infra/[replace]
[tool] init
[tool] plan  -var-file=clients/[client-code].tfvars
[tool] apply -var-file=clients/[client-code].tfvars

⚠

Never commit variable files that contain secrets or client identifiers to a shared repository. Keep per-client values in the client's own secret store or a restricted repository.

3 · Deploy the applications

[Replace: describe the pipeline, how images or packages reach the client environment, and how rollbacks work.]

❗

Agree up front who owns patching, upgrades, backups and incident response. A dedicated deployment without a clear operating agreement becomes an unsupported fork.

Which model to choose

If the client...	Lean towards
wants the fastest start and accepts a shared platform	Model A
has strict data-residency or sovereignty requirements	Model B (confirm with Legal and the DPO)
needs deep integration with internal systems	Model B, or Model A with private connectivity
has a small team and no appetite to run infrastructure	Model A

💡

A common path is to start on Model A for a proof of value and move to Model B only if requirements demand it. Design data export and import so that move is possible.