LM-Kit OneDocs2026.8.10lm-kit.com
Deployment

The Command Line

The lmkit executable has two jobs. Launched with no arguments, it IS the server. Launched with a verb, it is the operator's toolbox: everything provisioning scripts, golden images, and terminal diagnostics need, without opening a browser. lmkit --help lists every verb, lmkit <verb> --help its options, and every verb exits with a meaningful code, so each one doubles as a scriptable check. Verbs run OFFLINE against the installation's own state unless marked live below; the live ones talk to a running server over HTTP.

1Provisioning: models before first run#

lmkit models

Lists the model catalog with per-model download state, and:

lmkit pull gemma4:12b

downloads one by its catalog id, with progress, into the configured model directory. This pair is how an air-gap-bound or fleet image gets its models WITHOUT starting the server: pull on the build machine, ship the image, and first run serves immediately. Exit codes: pull returns 0 on success or already-downloaded, 1 on an unknown id or a failed download.

2Diagnostics: status, doctor, logs, devices, version#

  • lmkit status (live): is a server running here, and which one? Probes the configured local HTTP then HTTPS ports (or --url), and prints the running server's version, engine, and boot id. With --api-key, it also queries readiness: models loaded, active inferences, queue depth. Exit 0 running, 2 not running, so lmkit status && ... is a guard, not a grep.
  • lmkit doctor: the preflight. One pass over everything an installation depends on: state directory and its writability, model directory with downloaded count and free disk, visible compute devices, HTTPS certificate validity, Windows service registration, and a liveness probe. Every hard check prints [ok] or [!!]; exit 0 only when all pass, which makes lmkit doctor the first line of any provisioning script and the first ask on any support thread.
  • lmkit logs: the tail of server.log from the terminal: -n 200 for depth, --follow to stream new lines (rotation-safe). Exit 2 when no log exists yet. The Logs page remains the richer view; this is the SSH-only path.
  • lmkit devices: the compute inventory (number, name, type, memory), for verifying what the runtime will see before anything loads.
  • lmkit version: this EXECUTABLE's product and engine versions, offline. status reports the RUNNING server's; after an upgrade the two differ until the service restarts, and doctor points that out explicitly.

3The server as a unit: service and certificates#

  • lmkit service install | uninstall | status (Windows, elevated for install and uninstall) registers this executable as the Windows service, removes it, or reports registration (exit 2 when not registered). This is how a machine crosses between desktop mode and service mode; on Linux and macOS, the systemd unit and launchd job are the equivalents. Desktop installs deliberately run without a service, since the tray runs the server per session.
  • lmkit cert-info shows the HTTPS certificate (path, subject, thumbprint, validity, SANs); cert-export -o server.pem writes the public certificate for distributing trust to other machines; cert-install / cert-uninstall manage the OS trust store entry (normally automatic on first run; these exist for re-attempts and golden images).
  • lmkit cert-acme --enable --domains kb.example.com configures automatic TLS via ACME / Let's Encrypt (restart to apply), and cert-acme-status reports whether it is active. Going Live covers when ACME applies at all.

4The MCP bridge#

lmkit mcp --url http://localhost:5189 --api-key $LMKIT_API_KEY

Many MCP clients launch their servers as CHILD PROCESSES speaking newline-delimited JSON on standard input and output, and cannot open an HTTP session themselves. This verb is the adapter: point such a client at lmkit mcp as the command, and it bridges stdio to the running server's MCP endpoint, carrying session and protocol headers across and forwarding the server's progress events back. Standard output stays protocol-pure (diagnostics go to standard error), so the stream never corrupts. --path overrides a relocated endpoint; omit --api-key when the server accepts anonymous local calls.

5Conventions, stated once#

  • No arguments serves; any argument is a verb. There are no server-start flags: the server is configured by its settings file and the admin console, not by its command line.
  • Exit codes are the API. 0 is success, 1 is failure, and 2 is the scripted-check "false" (status down, service status unregistered, logs absent), so shell logic reads outcomes without parsing text.
  • Offline verbs act on the installation's own state (the same state directory the server uses), which is why running them as a different OS user than the service can see different paths; doctor prints the paths it acted on precisely so that mismatch is visible.
  • Help is a served answer. --help and version exit 0.

6Stated plainly#

  • One executable, two jobs: no arguments is the server, a verb is the toolbox.
  • pull and models provision headlessly; status, doctor, and logs operate from any terminal; service and cert-* make hosts; mcp adapts stdio clients.
  • Every verb exits meaningfully, so the CLI composes into scripts as naturally as the API composes into pipelines.