Operate Hubuum¶
A production deployment uses PostgreSQL, the Hubuum server, and the matching template-worker executable. Depending on your topology, background workers run with the API or as separate processes. Web restores need a separately supervised administrator restore executor.
Install and prepare¶
| Decision | Guidance |
|---|---|
| One host, optionally including the frontend | Single-host deployment |
| Multiple API or worker replicas | Distributed deployment |
| Native binaries | First server and configuration |
| One database login or separate privilege roles | PostgreSQL roles |
| Passwords and stable token keys | Secret sources and rotation |
| Local users, LDAP, or external policy | Identity providers and Treetop |
Pin the application versions you deploy. Run migrations as a one-shot workload before starting the new server. Follow the release's upgrade instructions and the distributed sequencing rules for mixed-version rollouts. The single-host installer can follow moving images, so select explicit server and frontend tags when you need a reproducible deployment.
Secure access¶
Configure TLS or a trusted reverse proxy, client allowlists, and proxy trust. Use group permissions and scoped service-account tokens for automation. Read credential approvals before upgrading credential-management integrations. Check login rate limiting when deploying multiple replicas.
Monitor and recover¶
Scrape each process's metrics, preserve structured logs, and enable tracing where needed. The repository includes Grafana dashboards, Prometheus alerts, and runbooks.
Establish a backup and restore procedure and exercise it before relying on it. Watch worker health and task retention, and size database pools using the capacity and tuning guidance.
For an incident, start with troubleshooting.