Deployment Overview

This article outlines the end-to-end process for deploying Immuta on self-managed infrastructure. Use it as a planning checklist alongside the cloud-specific deployment guides.

For the official Immuta self-managed deployment documentation, see Install Immuta.

Version Requirements

Component	Supported Versions	Notes
Kubernetes	1.29 – 1.35
PostgreSQL	15.0+	Extensions: pgcrypto, btree_gin. Incompatible with Amazon Aurora and other PostgreSQL abstraction layers.
Elasticsearch	v7 API or newer	AWS OpenSearch Serverless is not supported.
Helm	3.2.0+
Temporal	1.24.2+	Deployed by the Helm chart; connects to the same PostgreSQL instance.
Cache	Redis 7.0+ or Memcached 1.6+	Chart includes built-in Memcached; externalization is optional.

Avoid whitespace, $, &, :, \, /, and ' in database passwords. These characters can cause authentication failures or Helm value parsing issues.

Architecture Summary

An Immuta deployment consists of:

Component	Purpose	Options
Kubernetes cluster	Runs all Immuta services	AKS, EKS, K3s, RKE2
PostgreSQL	Metadata store (3 databases: immuta, temporal, temporal_visibility)	Cloud-managed (RDS, Azure Flexible Server) or in-cluster (CloudNativePG)
Elasticsearch / OpenSearch	Audit service backend	Cloud-managed (Elastic Cloud, Amazon OpenSearch) or in-cluster (ECK)
Temporal	Workflow orchestration (deployed by the Helm chart)	Connects to the same PostgreSQL instance
Ingress controller	External HTTPS access to the Immuta UI and API	Cloud-native (ALB, Azure App Routing) or third-party (nginx, Traefik)
Container registry	Hosts Immuta images (mirrored from ocir.immuta.com)	ACR, ECR, Harbor, or any OCI-compliant registry

Day 0: Infrastructure

Complete these steps before deploying the Immuta application. Cloud-specific guides cover each in detail:

• AWS Deployment

• Azure Deployment (AKS)

• K3s Deployment

• SUSE Rancher (RKE2) Deployment

Kubernetes Cluster

• Deploy a cluster with at least 3 nodes (minimum 4 vCPU / 16 GiB RAM each)

• Enable an ingress controller (e.g., AWS Load Balancer Controller, Azure App Routing, nginx)

• Attach or configure access to your container registry

PostgreSQL

• Deploy PostgreSQL 15+ with the pgcrypto and btree_gin extensions enabled

• Ensure the cluster can reach the database over the network (VNet peering, security groups, private endpoints)

• See In-cluster PostgreSQL using CloudNativePG for the Kubernetes-native option

• See Temporal with Amazon RDS for RDS-specific configuration

Elasticsearch / OpenSearch

• Deploy an Elasticsearch (v7 API or newer) or OpenSearch cluster for the audit service (AWS OpenSearch Serverless is not supported)

• See In-cluster Elasticsearch using ECK for the Kubernetes-native option

• See OpenSearch User Permissions if using Amazon OpenSearch

Networking and TLS

• Configure DNS for the Immuta endpoint hostname

• Obtain a TLS certificate for the endpoint (or use cert-manager for automated issuance)

• If mTLS between services is required, deploy a service mesh — see Service Mesh (Linkerd) options

• If deploying with a custom CA or trust chain, see Custom CA / Trust Chain

Container Images

• Mirror Immuta container images from ocir.immuta.com to your private registry using skopeo or a similar tool

• Required images: audit-service, cache, classify-service, detect-temporal-worker, immuta-db, immuta-service, temporal-admin-tools, temporal-proxy, temporal-server

Day 1: Deploy Immuta

Configure Databases

Create the immuta role and three databases. Each cloud-specific guide includes the exact SQL, but the pattern is:

1. Create a PostgreSQL role immuta with LOGIN

2. Grant the cloud-specific admin role to immuta (azure_pg_admin on Azure, rds_superuser on RDS, cloudsqlsuperuser on GCP)

3. Create databases: immuta, temporal, temporal_visibility (owned by immuta)

4. Enable the pgcrypto extension in the immuta database

5. Enable the btree_gin extension in the temporal_visibility database

6. Grant CREATE ON SCHEMA public to immuta in the temporal and temporal_visibility databases

Configure Elasticsearch / OpenSearch

• Create a user or API key with permissions to create and write indices

• Note the endpoint URL, username, and password for the Helm values

Create Kubernetes Secrets

• Create a TLS secret for the ingress certificate

• Optionally create secrets for database passwords or Elasticsearch credentials (or inline them in Helm values)

Install via Helm

helm upgrade --install -n ${NAMESPACE} immuta \
    oci://ocir.immuta.com/stable/immuta-enterprise \
    --version ${IMMUTA_VERSION} \
    -f immuta-values.yaml \
    --timeout 10m \
    --wait

Key Helm values to configure:

• global.imageRegistry — Your private registry

• global.imageTag — Immuta version

• global.postgresql.* — Database host, port, credentials, SSL

• audit.config.elasticsearch* — Elasticsearch endpoint and credentials

• secure.ingress.* — Ingress class, hostname, TLS secret

• temporal.server.config.persistence.* — Temporal database names and TLS settings

Validate the Deployment

• All pods should reach Running status (Temporal pods may take a few minutes to stabilize)

• The ingress should receive an external IP or hostname

• The Immuta UI should be accessible at https://<your-hostname>

• Configure the initial administrator account and apply the Immuta license

Day 2: Integrate

These steps are typically completed after a successful deployment but should be planned in advance.

Identity Provider

Configure SAML and/or SCIM with your identity provider:

• Entra ID (Azure AD) — SAML

• Entra ID — SCIM

• Okta — Attribute Mapping

• Okta — SCIM

Data Platform Connectors

Enable connectors for your data platforms in the Immuta UI. Verify outbound network connectivity from the Immuta namespace to each platform endpoint. You can test connectivity from an ephemeral pod:

kubectl run net-test --rm -it --image=curlimages/curl -n ${NAMESPACE} \
    -- curl -v <platform-endpoint>

Ongoing Operations

• Upgrades: See Upgrades & Migrations for version-specific procedures

• Backups: PostgreSQL backups are managed by your database provider (no longer handled by Immuta)

• Monitoring: Monitor pod health, database connectivity, and Elasticsearch cluster status