Stravia Docs

Deploy Stravia

This section covers installation and deployment decisions. Desktop is intended for local use with its integrated management interface. Server exposes the model API, management UI, and MCP endpoint; a production Server needs deliberate data, network, origin, proxy, and TLS configuration.

Choose a deployment path

  • Desktop : install the application for local management and inference. Desktop uses a native local session, not Server's first-run administrator setup.
  • Docker : run the official Server image with persistent data and a deliberately scoped published port.
  • Server binary : download the matching release archive, verify its published checksum, and select a data directory before first startup.

Configure the boundary around Server

  • Reverse proxy : configure the exact management origin and trust only the immediate proxy that connects to Stravia. Forwarded host and scheme must represent the external HTTPS origin consistently.
  • Databases : choose the supported SQLite or PostgreSQL backend and plan credentials, availability, and migrations.
  • Storage : choose local or S3-backed artifact storage, configure reachable URLs, and protect transfer grants.

Before exposing a Server

Do not publish a first-run example or 0.0.0.0 listener directly to an untrusted network. Configure the management origin and trusted proxy for the deployment, terminate TLS at an approved boundary, and restrict network access. CORS for the inference API is not a substitute for management-origin controls. A loopback-bound Docker example is useful for local testing, not a complete public deployment recipe.

After deployment

Keep the data directory persistent and private. Use Operations for backup, upgrades, storage, and diagnostics; a running health endpoint alone does not prove that setup is complete or a model is ready.