Installation and Checklist

Checklist before installation:

Intric is delivered on Kubernetes. Before you book time for installation with Intric, please verify that the following points are ready:

• Linux server (Ubuntu 22.04+) is set up according to the hardware requirements — or an existing Kubernetes cluster (version 1.29 or later) that Intric can be installed into.
• SSH access is arranged for Intric’s team (via VPN, tunnel or login credentials). If you operate your own Kubernetes cluster, cluster access (kubeconfig) instead.
• Ports 22, 80 and 443 are open.
• Outgoing traffic (whitelist for both infrastructure and language models) is configured in the firewall. In restricted environments this can be replaced by a private container registry that Intric’s images are mirrored into — fully air-gapped installations are supported.
• DNS records for the platform’s hostnames (application, API and sign-in) point to the server.
• SSL certificate is available in PEM format (full chain + private key). In an existing cluster, cert-manager can be used instead.
• Language-model providers are decided and their API keys are available — or endpoints for your own locally hosted models.
• SMTP details are available, if user invitations and password resets should be sent by email.
• Email address for the first administrator is determined.

Installation process:

When the above is ready, the installation will follow these steps:

1. Intric gets access to the server or cluster.
2. Kubernetes is installed (a lightweight distribution such as k3s), with storage and ingress configured — skipped if you provide an existing cluster.
3. The Intric platform is installed from its two Helm charts and configured for your environment: domains, certificates, model providers, email and firewall constraints.
4. A one-time bootstrap sets up the identity provider and creates your organization and first administrator account.
5. The installation is verified (see below).
6. Invitation is sent to your first administrator.

How the installation is verified

Before handover, the installation must pass the same checks Intric runs continuously against every version of the platform:

• Every component starts, reports healthy and stays running — application, API, identity provider, databases and processing workers.
• The identity bootstrap has completed and sign-in works end to end.
• Connectivity to the configured language model is proven along the same path the application uses — not just a network ping.
• In restricted environments: all images were pulled exclusively from your private registry, and the platform is confirmed to reach nothing outside the endpoints you have allowed.

Migrating from an existing installation

If you already run an earlier, Docker-based Intric installation, it is migrated to the Kubernetes platform rather than reinstalled from scratch. The procedure is designed so that no step is irreversible:

1. Backup first. The database, uploaded files, configuration and encryption keys are backed up, and every backup is verified restorable before anything else happens. The existing installation’s data is only ever read, never modified.
2. Install alongside. The Kubernetes platform is installed next to the existing installation — nothing is uninstalled or overwritten.
3. Restore data in. The database is restored into the new platform, file storage is synced over, and encryption keys and secrets are carried over unchanged so existing encrypted data remains readable.
4. Verify before switching. Sign-in is tested, migrated documents are opened, and data is spot-checked against the source. Only when verification passes is DNS repointed to the new platform.
5. Rollback stays available. The old installation is kept intact and untouched until you have signed off on the result — until then, rolling back is a matter of pointing DNS back. Nothing is deleted without your explicit sign-off.

Migration is done within an agreed maintenance window. If you run multiple Intric instances, they are migrated one at a time, starting with the least critical.