Choose an installation method
Choose an installation path for your operating environment
Choose an installation method
Choose how to install a shared Werft server for your team. Production installations use persistent object storage. Compose test-ops supports only AWS S3 and does not accept a custom endpoint. Kubernetes can use an S3-compatible endpoint that meets the protection contract. LocalStack and kind are test environments.
| Method | Execution backend | Requirements | Guide |
|---|---|---|---|
| Single server | One Linux server with Docker Compose. One worker container per session. HA is outside scope | Docker 28 or later, Compose 2.24.6 or later, Docker data-root on XFS mounted with prjquota, a repository checkout, and a persistent AWS S3 bucket | Single-server installation |
| Kubernetes | Published Helm chart. One worker Pod per session | A CNI enforcing NetworkPolicy, helm 3, PostgreSQL 16, and S3-compatible object storage (default protection requires a bucket with versioning, Object Lock, and SSE-S3 enabled). No repository checkout needed | Kubernetes installation |
Choose a single server if you want to operate one machine with scripts/test-ops.sh. Choose Kubernetes if you already have a cluster, PostgreSQL, and object storage and want chart-based installation. Both paths require access to published packages on ghcr.io without signing in. For existing installations, choose Upgrade Compose or Upgrade Kubernetes.
Both paths consist of the API (including the web console), scheduler, reconciler, egress proxy, PostgreSQL, and S3-compatible object storage. There is no Git server. Add the GitHub repositories sessions will use through the settings document or console.
| Goal | Start here |
|---|---|
| Production installation on one Linux server | Single-server installation |
| Production installation in an existing cluster | Kubernetes installation |
| Try the chart on a laptop | kind trial |
| Try Compose on Linux | LocalStack trial |
Operate after installation
For remote users, prepare access, then the first owner and keys, then model connections. Readiness checks cover database, schema, and configuration readiness. They do not prove actual model calls or restoration with data.
- Backup and restoration
- Upgrade Compose · Upgrade Kubernetes
- Capacity planning and changes · Recover stalled sessions
- Settings, keys, and ports · Storage and limits
- Session data flow · Datadog monitoring
Contributor and SDK documentation
The deployment package contract is for installers. Release publication and supply-chain policy is in the contributor documentation for publishers. The SDK approval sample is in the SDK documentation.