Skip to content
Docs

Configuration & Admin

Lifeboat separates deployment-time configuration (environment variables or a config file, set once by the platform team) from runtime administration (users, keys, models, servers, clusters — all managed in the browser).

How is Lifeboat configured at deploy time?

Section titled “How is Lifeboat configured at deploy time?”

Through environment variables, with an optional YAML configuration file, and an example environment file documenting every tunable. The main groups are:

Group Covers
Bootstrap First-launch administrator email and password — change these before production use
Paths Persistent data directory and the models directory (the models directory also gates which paths file deletion is permitted to touch)
Ports Control-plane port and node-agent port
Fleet The shared cluster secret used to authenticate control-plane-to-node calls
Supervision Maximum automatic restart attempts for a crashed inference server and the cooldown between them
Credentials A fallback Hugging Face token and the model cache location
Load balancer Queue depth, queue timeout, capacity gating, and connection caps — all optional, with working defaults
TLS Certificate and key for native HTTPS on the control plane

Configuration precedence runs command-line flags over the config file over defaults, and settings are persisted so a restart does not lose them.

What is configured per inference server rather than globally?

Section titled “What is configured per inference server rather than globally?”

Anything that is a property of how a model runs: the model, GPU selection and tensor-parallel width, quantization format, whether Lifeboat’s optimizations are enabled and how they are tuned, speculative decoding settings, and load-balancer weight and capacity for that server. This is deliberate — one deployment commonly runs an interactive server and a batch server with very different settings against the same fleet.

How are users and roles managed?

Section titled “How are users and roles managed?”

From the Users area of the control plane, with four roles:

Role Typical scope
Superadmin Full control including user management and sensitive operations
Admin Day-to-day administration of models, servers, clusters, and keys
Operator Operate servers and models without administrative control
Viewer Read-only visibility

Sessions are token-based, sign-in attempts are rate-limited per source address, and passwords are stored hashed. Role assignment and every user change are recorded in the audit log.

How are API keys and credentials administered?

Section titled “How are API keys and credentials administered?”

API keys authenticate inference traffic and are managed in the control plane — created (with the secret shown exactly once), paused, resumed, revoked, and deleted. An administrator can reveal a stored key when needed, and that reveal is itself audited. Hugging Face tokens live in a separate encrypted vault, can be pinned per model, and are managed independently of API keys.

What does the audit log capture?

Section titled “What does the audit log capture?”

Every administrative action: sign-in, sign-out, and failed sign-in; permission denials; server create/modify/lifecycle; model registration, download, and deletion; API-key and credential-vault changes; user changes; cluster changes; configuration changes; and node registration. The log is filterable by action, target type, time range, and user, and is retained in the persistent data directory.

Sources and references

Section titled “Sources and references”