On-Premise Installation

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.

Scenario B — Existing cluster

You already run Kubernetes and hand over a kubeconfig. The installer deploys the Helm charts into it and installs nothing else.

Scenario C — One Linux host

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

Requirements

Hardware, operating system, network, PostgreSQL, DNS and TLS — everything to have ready before the install starts.

Installation

The step-by-step install, from unpacking the bundle to a running platform.

Configuration Reference

Every value you must supply: the vault secrets, the Helm values, and the inventory.

Verification

How to prove the installation actually works, in the order the milestones depend on each other.

Operations

Upgrades, licence renewal, backups, logs, and what to do during a maintenance window.

Troubleshooting

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.

Introduction

Quickstart

Connectors

Integrations

Ecosystem Guides

Protocols

RKP-1 - Full On-Chain

RKP-2 - Off-Chain

RKP-3 - Hybrid

Data Sovereignty

Data Retention

Deployment Methods