Configuration overview

Kutrion is configured almost entirely through environment variables. There is one image and one codebase; the same build runs in local development, in staging, or on a customer’s own hardware. The only thing that differs between those environments is the .env file. There are no per-environment code branches and no hardcoded hosts, endpoints, or secrets baked into the build — everything that points at infrastructure is a variable you set, which is what makes the platform cloud-portable and safe to run air-gapped.

# A minimal self-hosted core
NODE_ENV=production
PORT=4000
APP_BASE_URL=https://vault.example.com
DATABASE_URL=postgres://vaultterm:[email protected]:5432/vaultterm
REDIS_URL=redis://cache.example.com:6379
REDIS_KEY_PREFIX=prod:
JWT_SECRET=replace-with-a-long-random-secret-at-least-32-bytes
KEY_PROVIDER=local
DEV_MASTER_KEY=<64 hex chars>

Where configuration lives

For self-hosting, the canonical template is deploy/onprem/.env.example. Copy it to .env, fill in the values for your environment, and pass it to the container (Docker Compose reads it automatically; an air-gapped install mounts it). The template is the source of truth for every variable the platform reads — the reference pages below describe the subset a customer running their own instance legitimately sets, grouped by concern.

In development the server falls back to safe local defaults (a localhost API origin, a dev master key, a dev signing secret) so it boots with almost no configuration. Those defaults are explicitly not safe for production, which is what the boot guards below exist to enforce.

Production boot guards

When NODE_ENV=production, the server refuses to start in a knowingly-insecure state rather than booting with a weak default. Two guards matter most:

• JWT secret guard. A weak, short, or dev-default JWT_SECRET is fatal under production. The secret must be at least 32 bytes and must not be the built-in development value. This prevents an instance from signing session tokens with a guessable key. See Authentication & sessions.
• Private-network egress guard. Server-side outbound fetches to private, loopback, and cloud-metadata targets (RFC1918 ranges, 127.0.0.0/8, link-local metadata addresses) are blocked unless you explicitly set EGRESS_ALLOW_PRIVATE=1, under every NODE_ENV. This is an anti-SSRF control: a webhook URL, SSO endpoint, or organization-level AI endpoint that resolves to an internal address will be refused unless you have opted in because you genuinely run those services on a private network. The guard covers HTTP(S) fetches, file connections (FTP, FTPS, WebDAV, S3-compatible, Azure Blob, Swift) and syslog delivery. See Core & database configuration.
• Broker target policy. SSH, SFTP and RDP connections are not HTTP fetches and are checked by a separate policy before the broker opens them. Reserved names (.test, .example, .invalid, example.com and similar) are refused, and every address a host name resolves to is checked, not only the first. Link-local and cloud-metadata addresses, multicast and other reserved ranges are always refused. Loopback is refused unless BROKER_ALLOW_LOOPBACK=1, and always when NODE_ENV=production. A host typed as a loopback, link-local, cloud-metadata or unspecified address, or as metadata.google.internal, is refused when the connection is saved. Private ranges (RFC1918, CGNAT, IPv6 ULA) follow BROKER_PRIVATE_TARGETS: unset or allow lets a self-hosted instance reach hosts on its own network, and any other value blocks them except for the CIDRs listed in SSH_BROKER_ALLOW_CIDRS. An organization admin can block private targets for their own organization but cannot loosen a deployment-wide block. Refusals are written to the audit trail.

Other production behaviors follow the same fail-closed principle — for example the Prometheus /metrics endpoint requires a token under production rather than serving openly. These are documented alongside the variables that control them on the reference pages.

Reference pages

The full variable reference is split by concern:

• Core & database configuration — server, networking, PostgreSQL, Redis, observability, egress, the broker target policy, and the RDP gateway.
• Authentication & sessions — tokens, WebAuthn, SSO, and social login.
• Keys & licensing — the key provider, master-key binding, hardware root, and on-prem licensing.
• AI & egress integrations — the AI provider and transactional mail.

For the bigger picture, see Self-hosting overview and Architecture overview.