Release images
Pin the app image that matches the release notes.
Release automation publishes version, latest, and short-SHA tags to GHCR and Docker Hub after CI, Fly deploy, and health checks pass. It can also publish the same tags to Quay when the release workflow has QUAY_USERNAME and QUAY_TOKEN. For stable self-hosting, pin a version tag such as ghcr.io/taimoorq/logister:v2.6.1 or docker.io/taimoorq/logister:v2.6.1 and review the matching changelog entry before upgrading.
Process model
The Docker shape mirrors the Rails app architecture.
| Container | Responsibility |
|---|---|
| Web | Runs the Rails UI, auth, project management, dashboards, and ingest endpoints. |
| Worker | Runs Sidekiq for email delivery, first-occurrence alerts, digests, async ingestion, optional ClickHouse writes, and archive/prune tasks. |
| PostgreSQL | Stores accounts, projects, API keys, events, grouped errors, notification preferences, and sharing. |
| Redis | Backs Sidekiq, caching, and rate-friendly dashboard behavior. |
| S3-compatible storage | Optional Active Storage target for compressed telemetry archives. |
| ClickHouse | Optional analytics store for higher-volume event and span exploration. |
Self-hosting choices
Use managed data stores or a single-host stack.
Teams can run only the Logister web and worker containers while using managed PostgreSQL, Redis, and SMTP, or they can use a Compose-style single-host stack for the full footprint. The same environment reference applies in both cases.
- Keep secrets in the deploy platform or host secret store, not in the repository.
- Run database migrations in a release phase or explicit one-off task.
- Keep at least one worker process running so email, digests, and async ingestion continue.
Next steps