P0-6: Deploy the crash-report collector (off-homelab) #42

New issue

Open

opened 2026-09-10 17:57:20 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-10 17:57:20 +00:00

Owner

Manual/infrastructure task. Prerequisite for P3-6 (opt-in error reporting).

Goal

A self-hosted crash-report collector that customer clients can reach from the public internet.

Where it must not live

Not on the homelab cluster. That infrastructure sits behind CGNAT with a VPS/WireGuard hop, and it is the development environment — pointing customer machines at it couples product availability to a home network and exposes an inbound path to it. Wrong place, for both reliability and security reasons.

Where it should live

Alongside the licence server (license.swisscairn.ch) on the VPS, or on a dedicated small VPS. It is a container either way:

Docker Compose on the existing VPS — simplest, matches how the licence server is already operated. Recommended unless there is a reason to grow the surface.
A Kubernetes pod — only if a managed cluster already exists off-homelab. Do not stand up a cluster for one collector.

Suggested: errors.swisscairn.ch, TLS via the existing Caddy setup.

What to deploy

GlitchTip — Sentry-compatible API, far lighter than self-hosted Sentry (which wants a dozen services and several GB of RAM), and the Sentry SDKs work against it unmodified. Self-hosted Sentry is the alternative if you later need its full feature set; start with GlitchTip.

Requires: the app container, PostgreSQL, Redis. Modest resources.

Constraints that follow from the product's promise

Retention: short. 90 days maximum. This is diagnostics, not analytics. Holding crash data indefinitely from a product that sells data sovereignty is indefensible if anyone looks.
No third-party processor. That is the entire point of self-hosting it — GlitchTip's own hosted service would defeat the purpose.
The client sends nothing unless the user opts in (P3-6), and shows exactly what it will send first.
Document it in the privacy statement alongside the §8.3 wording: the server never phones home; the client does two optional things, both switchable off.

Steps

Decide: VPS Docker Compose vs dedicated host.
Deploy GlitchTip (app + PostgreSQL + Redis) with a compose file kept in version control.
Terminate TLS through the existing Caddy configuration; add the DNS record.
Create the project; record the DSN for P3-6.
Set retention to 90 days.
Configure backups for the database — a crash collector with no backup is a monitoring tool that loses its own data.
Verify end to end: send a test event from a throwaway client build and confirm it appears.

Acceptance criteria

Collector reachable over HTTPS from outside the LAN.
Not hosted on the homelab cluster.
Retention capped at 90 days.
DSN recorded for P3-6.
A test event round-trips.

**Manual/infrastructure task.** Prerequisite for P3-6 (opt-in error reporting). ## Goal A self-hosted crash-report collector that customer clients can reach from the public internet. ## Where it must not live **Not on the homelab cluster.** That infrastructure sits behind CGNAT with a VPS/WireGuard hop, and it is the development environment — pointing customer machines at it couples product availability to a home network and exposes an inbound path to it. Wrong place, for both reliability and security reasons. ## Where it should live Alongside the licence server (`license.swisscairn.ch`) on the VPS, or on a dedicated small VPS. It is a container either way: - **Docker Compose** on the existing VPS — simplest, matches how the licence server is already operated. Recommended unless there is a reason to grow the surface. - **A Kubernetes pod** — only if a managed cluster already exists off-homelab. Do not stand up a cluster for one collector. Suggested: `errors.swisscairn.ch`, TLS via the existing Caddy setup. ## What to deploy **GlitchTip** — Sentry-compatible API, far lighter than self-hosted Sentry (which wants a dozen services and several GB of RAM), and the Sentry SDKs work against it unmodified. Self-hosted Sentry is the alternative if you later need its full feature set; start with GlitchTip. Requires: the app container, PostgreSQL, Redis. Modest resources. ## Constraints that follow from the product's promise - **Retention: short.** 90 days maximum. This is diagnostics, not analytics. Holding crash data indefinitely from a product that sells data sovereignty is indefensible if anyone looks. - **No third-party processor.** That is the entire point of self-hosting it — GlitchTip's own hosted service would defeat the purpose. - **The client sends nothing unless the user opts in** (P3-6), and shows exactly what it will send first. - **Document it** in the privacy statement alongside the §8.3 wording: the server never phones home; the client does two optional things, both switchable off. ## Steps - [ ] Decide: VPS Docker Compose vs dedicated host. - [ ] Deploy GlitchTip (app + PostgreSQL + Redis) with a compose file kept in version control. - [ ] Terminate TLS through the existing Caddy configuration; add the DNS record. - [ ] Create the project; record the DSN for P3-6. - [ ] Set retention to 90 days. - [ ] Configure backups for the database — a crash collector with no backup is a monitoring tool that loses its own data. - [ ] Verify end to end: send a test event from a throwaway client build and confirm it appears. ## Acceptance criteria - Collector reachable over HTTPS from outside the LAN. - Not hosted on the homelab cluster. - Retention capped at 90 days. - DSN recorded for P3-6. - A test event round-trips.