> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootkey.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# On-Premise Installation
> Install the ROOTKey Data Plane inside your own infrastructure — one Linux host or an existing Kubernetes cluster, with egress-only or fully air-gapped connectivity.
## What Gets Installed
An on-premise installation places the complete ROOTKey Data Plane inside your perimeter. Users authenticate against it, files are stored in it, and anchoring transactions are signed by wallets that never leave it.
The installer deploys **24 workloads** as a single Helm umbrella chart, plus three stateful dependencies it runs in-cluster:
| Component | Where it runs | Why |
| -------------------------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Data Plane services** (24 workloads) | In-cluster, one Helm release | The platform itself: API, frontend, workers, schedulers. |
| **Redis** | In-cluster | Queues and caches. Self-owned so the installation has no external dependency. |
| **Kafka** | In-cluster | Event bus between services. Self-owned for the same reason. |
| **MinIO** | In-cluster | Object storage, S3-compatible. This is where uploaded files live. |
| **PostgreSQL** | **Outside the cluster** | Databases outlive clusters. Running it as a pod makes a restore a Kubernetes problem rather than a database one. |
PostgreSQL is deliberately **not** a container. In Scenario C the installer provisions it natively on the host with systemd; in Scenario B you supply a managed or dedicated endpoint. Either way it is external to Kubernetes, so a cluster rebuild never touches your data.
***
## How It Works
```
Your Network Perimeter ROOTKey Control Plane
────────────────────── ─────────────────────
Users ──HTTPS──► Platform frontend Issues the licence
│ Receives heartbeats
▼ Publishes the catalogue
ROOTKey Data Plane
24 workloads, one Helm release
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Redis Kafka MinIO ──mTLS/443──► (egress-only mode)
│ or no link at all
▼ (air-gapped mode)
PostgreSQL
(outside the cluster)
```
The Data Plane runs independently. The Control Plane link carries **licensing, telemetry and catalogue updates only** — never your files, never your users, never file content or metadata.
***
## Choosing a Scenario
Two questions decide almost the entire installation: **what infrastructure will you provide**, and **what network connectivity is permitted**.
You already run Kubernetes and hand over a kubeconfig. The installer deploys the Helm charts into it and installs nothing else.
You hand over SSH access to a single Linux machine. The installer sets up k3s, PostgreSQL, and the full platform on it. **The most common choice** for banking, defence and other conservative environments.
| | Scenario B | Scenario C |
| ----------------- | ------------------------------------- | ---------------------------------- |
| You provide | A Kubernetes cluster + kubeconfig | One Linux host + SSH access |
| Kubernetes | Yours | k3s, installed by us |
| PostgreSQL | Yours (managed or dedicated endpoint) | Installed natively on the host |
| Deployed artefact | The Helm chart | The Helm chart |
| Typical for | Cloud-native organisations | Conservative IT, regulated sectors |
***
## Choosing a Connectivity Mode
| Mode | Inbound | Outbound | Licensing | Updates |
| --------------------------- | ------- | -------------------------------------------------- | --------------------------------------------- | ----------------------------- |
| **Egress-only** *(default)* | None | Allowlist to the ROOTKey Control Plane (mTLS, 443) | Online heartbeat | Pulled from the Control Plane |
| **Air-gapped** | None | None | Offline signed licence, supplied in the vault | New bundle delivered by hand |
Egress-only suits most regulated clients: nothing reaches in, and the single outbound destination is one you can name in a firewall rule. Air-gapped suits defence and isolated core networks, at the cost of updating by hand.
In egress-only mode the licence is renewed over the Control Plane link. A deployment whose egress rules omit the Control Plane fails in the most misleading way available: it **enrols, goes quiet, and reports healthy** until the grace period expires, because serving from a cached licence is normal operation rather than an error. Confirm the allowlist before the install, not after.
***
## What the Installation Does Not Do
Stated plainly, because scoping an on-premise install is mostly about what stays yours:
* It does **not** send file content, file metadata, user records or organisation data to ROOTKey. The Control Plane link carries the licence, heartbeat counters and catalogue versions.
* It does **not** require inbound access from the internet. Nothing outside your network needs to reach the installation.
* It does **not** manage your DNS or issue your certificates. You supply the hostname and the TLS certificate; the installer consumes them.
* It does **not** modify infrastructure outside the namespace it installs into, other than the host-level packages Scenario C explicitly needs (k3s, PostgreSQL, a firewall rule).
***
## Installation Guides
Hardware, operating system, network, PostgreSQL, DNS and TLS — everything to have ready before the install starts.
The step-by-step install, from unpacking the bundle to a running platform.
Every value you must supply: the vault secrets, the Helm values, and the inventory.
How to prove the installation actually works, in the order the milestones depend on each other.
Upgrades, licence renewal, backups, logs, and what to do during a maintenance window.
Every failure we have hit on a real installation, with the command that identifies it.
***
→ Looking for the commercial overview instead? See [On-Premise Deployment](/pages/deployment/on-premise).