Deploy and Operate
This section covers deploying Orloj to any environment and running it in production.
Deployment Targets
Choose a deployment path based on your environment:
| Target | Best For | Persistence | Process Management | Scope |
|---|---|---|---|---|
| Local | Development and rapid iteration | Optional (memory or Postgres) | terminal or Docker Compose | single operator machine |
| VPS | Single-node production-style self-hosting | Postgres volume | systemd + Docker Compose | small internal workloads |
| Kubernetes | Cluster-based operations and lifecycle controls | PVC-backed Postgres | Kubernetes deployments | platform-managed environments |
- Local Deployment
- VPS Deployment (Compose + systemd)
- Kubernetes Deployment (Helm + Manifest Fallback)
- Remote CLI and API access -- tokens,
orlojctlprofiles, andconfig.jsonafter you expose the control plane
Hosted Stack, Local CLI
When the control plane runs in Compose, Kubernetes, or GHCR images, install orlojctl alone on the machine you use to operate the cluster: download the orlojctl_* archive for your OS and arch from GitHub Releases (see Install: CLI only for hosted deployments). Then follow Remote CLI and API access for --server, tokens, and optional profiles.
Day-to-Day Operations
- Configuration -- flags, environment variables, and runtime tuning
- Runbook -- startup, verification, and incident response
- Security and Isolation -- secrets, auth, and network hardening
- Upgrades and Rollbacks -- version migration procedures
- Troubleshooting -- common issues and debugging
Observability
- Observability -- OpenTelemetry tracing, Prometheus metrics, structured logging
- Monitoring and Alerts -- alerting rules and dashboards
- Backup and Restore -- data protection procedures
Security Defaults
- Rotate default secrets before non-local use.
- Restrict network exposure to required interfaces.
- Keep API auth strategy explicit for each target.
- After deployment, configure remote CLI access (API tokens, env vars, optional
orlojctl configprofiles).