If clients opt for self-hosted options, either Customer Managed Tenant or On Premise Tenant, they (potentially with Uniques Advisory at a rate) must equally provide all necessary pieces in order to satisfy the setup and run requirements.

You can learn about them in the respective models details linked above.

Note that this page gives a high-level overview. For Customer Managed Tenant clients can use the https://unique-ch.atlassian.net/wiki/x/JAEkJQ to further cross-check their tenant for the arrival of Unique.

Providing a tenant (1)

It does not matter what deployment model is chosen, a client has to provide a landscape that can provide user accounts (IAM, IDP, potentially Just-In-Time or Privileged Access Management).

The requirements are vastly different per client and per option (customer managed or on premise) and are always already regulated by the client internally. Unique can advice but most clients have this set in stone how it will work except if they started to adopt the cloud a week before where it would not be realistic to run Unique there within reasonable time (in that case, look in the direction of the Single Tenant).

Networking

From the inter-/intranet to Uniques deployment lead many ways. The planning and implementation as well as maintenance of the way is the clients responsibility. Unique has a Reference Architecture CMT which uses an internet facing Application Gateway but if clients would like to wire Unique differently, they must do so on their own knowledge and expense if needed with advisory at a rate.

Hosting Unique / Dedicated resources (2)

Clients must provide means to provision a set of resources needed to run Unique successfully. Depending on the use cases, more or less of these services are needed.

Brick	Use Case	Use Case

Brick	Use Case	Use Case
Container orchestrator¹	chat recording	Our applications
Telemetry exported to the orchestrator²	chat recording	Alert First Level Support
Logging solution attached to the orchestrator	chat recording	Retain application logs for 7-30 days
Secure Storage for Audit Logs as volumes attached to the orchestrator	chat recording	Retain application audit logs for regulated time period
Postgres Server³	chat recording	Persisting application data
MongoDB³	recording	Persisting application data
Redis Cache(s)³	chat	Tyk API Gateway Frontend Websockets
Speech Services (mainly Azure Cognitive Services)	recording	Transcribe audio to text
LLMs³ (mainly Azure OpenAI)	recording	Reporting features
LLMs³ (mainly Azure OpenAI)	chat	Chat features
Ceph/S3 compatible storage³	recording	Video storage
Ceph/S3 compatible storage³	chat	Knowledge features Sharepoint Connector and others
Azure AD Application Registration	chat recording	Login with Teams

¹ Unique currently only supports Kubernetes as orchestrator. Other orchestrators are available at a premium.

² Unique currently only supports Prometheus as metrics export. Other solutions might be available at a premium.

³These services can also be self-hosted on top of the orchestrator which is discouraged but possible. The client is responsible for these workloads.

Workload configurations and supporting services (3)

Brick		Use Case

Brick		Use Case
Postgres Server¹	chat recording	Persisting application data
MongoDB¹	recording	Persisting application data
Redis Cache(s)¹	chat	Tyk API Gateway Frontend Websockets
LLMs¹ (mainly Azure OpenAI)	recording	Reporting features
LLMs¹ (mainly Azure OpenAI)	chat	Chat features
S3 compatible storage¹	recording	Video storage
S3 compatible storage¹	chat	Knowledge features Sharepoint Connector

¹These services are recommended to be provisioned outside of the orchestrator, see (2).

Unique workloads (4)

The Unique workloads themselves have no requirements except all the services mentioned above, CPU and memory. Some require some disk space to locally ephemerally cache file or similar content.

Supporting tooling

Both Customer Managed Tenants as well as On Premise installations might not be able to leverage all internet facing tooling Unique provides.

You can get familiar with those in Release Process.

Some key bullets in that regard are:

The orchestrator has no internet access
- Unique advises against pulling directly from our docker registry as it is a central, single point of failure or more importantly the client does not want to directly run images from Unique
The cluster ing- and e-gress is restricted or isolated from the internet
The client must always apply some customisations on their side (especially around Vaults and Secrets)
The deploying entity/machine has no internet access

Depending on a clients setup, further tooling is needed on site so either within their tenant/environment or also On Premise.

Tool	Use Case	Examples

Tool	Use Case	Examples
Git or another VCS	Store versioned Unique artefacts as code for audits, infrastructure as code, customisation and automation etc.	GitHub (Cloud) GitHub Enterprise Azure DevOps GitLab Enterprise
(CI/) but especially CD Automation	Automation and Principals that apply code changes published by Unique	GitHub Actions Azure DevOps Agents GitLab CI Bitbucket Pipelines Octopus Or more futuristic: FluxCD ArgoCD
Container Registry	Cache, scan, analyze container images delivered by Unique as part of the Release Process. In order to mirror the images the Automation above can be reused.	Azure Container Registry Harbor DockerHub Github Packages
Helm Chart Gallery	Cache, validate helm charts delivered by Unique as part of the Release Process. In order to mirror the charts the Automation above can be reused. This must also be used to potentially cache public helm charts as Unique does not re-deliver open source components!	Azure Container Registry Harbor Chart Museum
Secrets Management	When deploying and maintaining Unique (incl. via Helm Charts), secrets must be provided to the workloads. The Secrets Management is highly dependent on the Clients eco-system.	External Secrets Octopus Sealed Secrets Secrets Store CSI Driver

Author	@Dominik Meyer

Public Documentation

Infrastructure requirements