Skip to main content
install.env holds every setting the installer reads. Copy install.env.example to install.env, uncomment what you need, and leave the rest alone to keep the defaults.
The file is sourced by both entrypoints and exported to every component script. It is git-ignored. Never commit it: it holds credentials. This page is a lookup table. For the reasoning behind a group of settings, follow the links in each section.

Identity

Set these first. Every resource name and hostname derives from them.

Pre-existing Resources

Set these when your infrastructure does not follow the <PREFIX>-<suffix> naming. Each one bypasses the derived lookup.

DNS and TLS

See Set custom domain and certificates for the hostname list and the required certificate names.

Image Registry

A full image reference is <REGISTRY_BASE>/<REGISTRY_PATH_*>/<image>. See Install package.
NVCR_REGISTRY and K8S_REGISTRY default to routing through REGISTRY_BASE like every other image. Setting them explicitly to nvcr.io or registry.k8s.io makes those components pull straight from the public internet, which breaks an air-gapped install. Leave them unset unless you know you want that.
Pointing STORAGE_CLASS at a class you already have, without also setting ENABLE_CLUSTER_PREREQS=false, makes Helm take ownership of it. A later uninstall then deletes it.

Registry Seeding

Off by default. See Seed your container registry.

Feature Toggles

Each component self-gates on its own flag. See Install System (AWS EKS) for the full list and the dependency warnings. On-premises infrastructure, all default true. Set to false on a managed cluster that brings its own. GPU GPU sizing is not set here. See GPU profiles and values overlays.

Notifications

notification-core sends transactional email, such as assignment and review-request notifications. It is off by default, and the SMTP values it ships with are placeholders rather than a working relay. Supply your own relay details and verify that mail is delivered before you enable it.
An empty WHITE_LIST_EMAIL_DOMAINS means send to everyone, not block everyone. The service treats an empty list as no restriction. Set it on any non-production install, or a test run mails real customers.
In seed mode the installer inlines SMTP_PASSWORD into YAML with awk, so a password containing a double quote, a backslash, or a newline corrupts the file. Use a secret backend for passwords like that.Setting MAILER_PROVIDER=smtp explicitly makes front send even when notifications are disabled, because its SMTP path ignores the enable flag. Set SMTP_HOST too, or it dials the placeholder host and mail silently goes nowhere.

Secret Backend

See Secrets and Vault for the full path and key inventory.

In-cluster Vault

External Vault

This section applies only if you already run your own HashiCorp Vault and want LILT to read its secrets from it, instead of from the Vault that ships in the tarball. If you are using the shipped one, skip this section entirely: it authenticates with a Kubernetes service account token and needs none of these settings. To use your own Vault, set three things:
Set ENABLE_VAULT=false as well. The shipped Vault and your own are mutually exclusive, and two secret stores of the same name must never be active on one cluster.

The AppRole Credentials

The AppRole role ID and secret ID are deliberately not install.env variables. There are no VAULT_ROLE_ID or VAULT_SECRET_ID settings, and no install script reads them from the environment, so they never pass through a file that could be committed or a shell that logs its arguments. Instead, External Secrets reads them from a Kubernetes Secret named vault-approle in the external-secrets namespace. Create it before you run the installer:
The key names matter: role-id and secret-id. The installer never creates this Secret and stops with an error if it is missing. The AppRole you use needs read access to every path in the secret inventory. See Secrets and Vault.

Advanced

Escape hatches. Do not set these without a reason.