Deployment
Run the same runtime in your cloud or on-premises. Plan the database, model services, storage, and credentials alongside the binary.
Deployment modes
| Mode | What it means | Best for |
|---|---|---|
| Your cloud | Your infrastructure and configured data boundary | Firms with a cloud footprint and compliance requirements |
| Air-gapped on-prem | Your hardware, local models and dependencies, external connections disabled | Work that must stay within an isolated environment |
The Developer License MVP is an account or organization record, not an activation mechanism. The Runtime does not validate a local license, phone home to enforce licensing, or unlock features through that record. Permitted use is governed by the LICENSE distributed with your release and any applicable commercial agreement.
Hosting your apps in LibraOS Cloud is planned and not available yet. The Console builds apps and sells model access today; its Deploy page points to the reference stack for running them on servers you control. To discuss a private deployment, see pricing.
On-premise deployments can also run networked behind your firewall if full air-gapping is not required. Self-hosting alone does not keep model or connector requests local: external providers receive the information sent to them.
The binary size varies by release. A working deployment also needs a database, model endpoint, and any storage or tool backends required by the application. The quickstart covers the minimum configuration.
Air-gapped operation requires local generation and embeddings plus tools that work inside that boundary. Verify effective capabilities and data flow before disconnecting the deployment.
What ships in the binary
- The kernel and knowledge base
- The AI firewall (three-tier screening)
- The agent runtime; create definitions through APIs, files, or available setup tooling
- Compatible API endpoints that call models served by your configured gateway
Secrets & environment
The server is its own identity provider: every login session and API token it
issues is signed with LIBRA_OS_JWT_SECRET. The
getting-started guide shows how to generate it; for a
production deployment, also plan for:
- Replicas share one secret. Every instance behind a load balancer (or in
a blue/green pair) must run the same
LIBRA_OS_JWT_SECRET, or tokens minted by one replica are rejected by the next. - Store it like a credential. Put it in your secret manager and inject it at start — not in shell history, unit files, or compose files checked into git. With auth enabled the server refuses to boot if the secret is unset, a known default, or shorter than 16 bytes.
- Rotation logs everyone out. Changing the secret invalidates every outstanding session and token at once. That makes rotation a deliberate, announced event — useful after a suspected leak, disruptive as routine hygiene.
- Token lifetime is tunable.
LIBRA_OS_ACCESS_TOKEN_TTLsets how long issued tokens live (a Go duration such as720h; unset defaults to 1 hour). Longer lifetimes trade fewer re-logins for a longer exposure window on a leaked token — and a wider blast radius when you do rotate the signing secret.
libraos doctor deployment audits all of this — environment, database, LLM
gateway, and the running server — and prints a fix line for anything wrong.
Knowledge base & retrieval
Which backend actually holds vectors, how to confirm retrieval is working, and how to scope auto-indexing: see Knowledge base & retrieval. If you are upgrading a Runtime from before v0.1.18, read the auto-indexing note there first — the default changed.
Reference stack
For a container-based deployment, see the reference docker-compose stack — the core server plus optional companion apps.
Sizing, connectors, and support are scoped per deployment. See pricing or book a demo.