Going Live

How to take a working localhost installation and expose it to other machines without weakening it: what changes at the network boundary, how HTTPS is provisioned, how the server runs unattended, and which files constitute the installation. Complete deployment shapes, from workstation to air-gapped enclave, are sketched in Reference Architectures.

1The two network postures#

The server runs in one of two modes, set in the admin panel's Network section (a restart rebinds the listeners):

The two directions of a posture change deliberately behave differently. Saving Network withdraws anonymous access at once, before the restart that widens the listeners, because the restrictive half of the change is safe to apply early. Saving Local only does not grant anonymous access back until the restart has actually narrowed the sockets, because until then they are still reachable from other machines. There is no configuration in which the server is both reachable from the network and callable without a credential.

2Before you flip the switch#

1. Mint the keys. Once the posture is Network, keyless calls are refused, so every caller needs a key first (see Keys and Authentication; keys live in Access). New keys start with no Search access; grant what each caller needs.
2. Create the operator accounts. On a loopback install the admin console may run without one; on a network-reachable server it must not. Setting the first password creates the admin operator account you sign in with; then add one named account per human, with a role bounding what each may change and their own second factor (Operator Accounts carries the roles, break-glass recovery, and the SSO and two-factor options).
3. Review the Interfaces section. Each web destination (API reference, guides, playground, training, MCP guide) has its own served-or-not toggle and access level (public or admin session). Decide which surfaces a network visitor should see at all.
4. Review tool egress. If server-executed tools are enabled, check the Tools section's network policy so a model cannot be steered into reaching hosts you did not intend (the layers are Tools and Egress).

3HTTPS#

• Out of the box, the server generates a self-signed certificate on first run and attempts to install it into the OS trust store, so local HTTPS works without ceremony. The lmkit cert-info, lmkit cert-install, and lmkit cert-uninstall commands inspect it, re-attempt the trust installation, or remove it.
• For a public DNS name, enable ACME in the configuration (AcmeEnabled, with the name listed in AcmeDomains and the terms-of-service flag set): the server then obtains and renews a publicly trusted certificate on its own, provided the name resolves to this host and the HTTPS port is reachable for validation. A staging switch exists for testing so you do not burn issuance rate limits.
• The admin console can be restricted to HTTPS-only with the corresponding Security setting.
• Behind your own ingress (nginx, Caddy, Traefik), TLS usually terminates at the proxy; the buffering, timeout, and forwarded-header specifics that keep streaming working are Behind a Reverse Proxy.

4Running unattended#

Two supervision styles, both using the same binary and the same state:

• Desktop mode: the tray application starts the server for the logged-in user session and restarts it if it dies. Right for a workstation.
• Windows service: lmkit service install registers the service (with service status and service uninstall beside it), so the server runs without a logged-in session and starts with the machine. Right for a server. The installer can also register it at install time.

On Linux, run it under systemd like any other service; the process supports systemd notification. Containerized deployments build their own image today (Running in Containers); fleet-grade Windows rollout, silent MSI and service mode included, is Windows Server Deployments. And when one server becomes several behind a load balancer, the whole contract is Scaling Out.

5Where the installation lives#

Everything the server writes resolves under ONE state directory, decided at startup and printed in the startup log:

• the executable's own directory when it is writable (portable installs, services, dev builds);
• otherwise a per-user data directory, so a machine-wide install never asks users to write next to the binaries;
• LMKIT_STATE_DIR pins it explicitly.

The state directory holds the runtime settings file, the API key store, logs, certificates, uploads, and the sidecar stores. Models live separately, under the model directory shown in the Models section (overridable with LMKIT_MODELS_DIR).

Backups: the state directory is the installation. Copy it and you have the settings, keys, and history; models can always be pulled again, so back them up only if bandwidth matters more than disk. The full runbook, upgrades and rollbacks included, is Backup and Upgrades; deployments with zero egress have their own recipe in Air-Gapped Deployment.

6Stated plainly#

• Network posture and anonymous access are one decision, resolved so the unsafe combination is unrepresentable.
• A network-reachable server authenticates every API call; there is no partially open state.
• Every human-facing surface is individually serveable and gateable from the Interfaces section.
• One directory carries the installation's identity; the startup log names it.