LutraIDDocumentation

Self-hosting

LutraID runs on your infrastructure, in your network, under your control. Issuer signing keys stay in your key manager, citizen data stays in your database, and no subprocessor sits between you and your users.

What you receive

  • Name
    Registry credential
    Type
    username + password
    Description

    Read-only, scoped to your own namespace registry.lutralabs.io/customers/<your-slug>. Pulls releases and nothing else — it cannot see other customers' namespaces, and it cannot push or delete, even inside your own.

  • Name
    Release version
    Type
    vX.Y.Z
    Description

    The version you install, for example v0.34.28, and the one support is answered against. Every release is published to your namespace as soon as it has passed its install test.

  • Name
    License
    Type
    signed token
    Description

    Verified locally. LutraID never calls home.

When the license arrives. An evaluation license can be issued up front. A production license is bound to your installation's ID, which only exists once LutraID has started for the first time — so you install first, send us the ID, and install the license you receive. Until then LutraID runs normally inside a 30-day onboarding window. See License.

Choose a package

Kubernetes + HelmDocker Compose
Supported forProductionEvaluation, development, small non-HA production
High availabilityYesNo — single host
Zero-downtime upgradeYesNo
DatabaseYours, externalOn the host

Compose is a real deployment, not a demo. It is simply one machine: no failover, no rolling upgrade, and the database sits beside the application. Choose it deliberately.

From download to a licensed installation

  1. Requirements — the tools you need, and the decisions to make before the first install.
  2. Download and verify — pull the release from your namespace and prove it is the one Lutra Labs published.
  3. Install with Docker Compose — one command, ./install.sh — or with Helm.
  4. License — your installation ID, installing the license, and what happens as it ages.
  5. Upgrades and air-gap — moving to a new release, mirroring into your own registry.
Start with the requirements

What never phones home

License verification is entirely offline — no license server, no JWKS endpoint, and no telemetry unless you configure it. The public key that validates your license is compiled into the image you already have.

The only outbound connections LutraID needs are to your own database, your own cache, and your own mail relay. Air-gapped installation is supported: see Upgrades and air-gap.

Sovereignty

Self-hosting removes every subprocessor from the picture. Mail goes through your relay, object storage is your disk or your S3, and analytics are off unless you turn them on. For a public-sector deployment this is usually the reason the option exists.

Getting help

Write to info+support@lutralabs.io, or the channel named in your agreement. Include:

  • the release version and the image digests you are running (images.yaml from the release bundle)
  • your installation ID
  • which package — Helm or Compose — and whether the site is air-gapped
  • the output of GET /v1/admin/license, or the license state from the boot log
  • logs from backend, and from the migration Job if the problem is an upgrade

Report a vulnerability through the disclosure process in your agreement rather than through normal support.

Was this page helpful?