Self-Host GlitchTip with Greffon
Error tracking sees every stack trace and request your apps throw. That is a lot of trust to hand a vendor. Here is the honest setup for GlitchTip on a greffer you own.
Error tracking is one of the most revealing things you can run. The stack traces, request payloads, and breadcrumbs it captures can carry user emails, tokens, and the shape of your whole system. Sending all of that to a vendor is a real decision, not a default. GlitchTip is a Sentry-compatible error tracker you can host yourself, so the events stay on a machine you own, and Greffon takes the fiddly parts off your plate.
Why own your error tracking
GlitchTip speaks the Sentry API and works with the official Sentry SDKs, so the client libraries you already use in Python, JavaScript, Go, and the rest point at it unchanged. It is a leaner reimplementation rather than the full Sentry stack, which is the point: it covers error and performance events without the operational weight of running Sentry itself, so it fits on a modest greffer.
Hosting it yourself changes where the data lives, not how you use it. The events your apps capture land in your own database instead of a vendor account, which matters most when those events carry anything you would not want to ship off-site.
Graft it from the catalog
On a greffer you do not hand-write a compose file or wire a reverse proxy. Pick GlitchTip from the catalog and graft it onto your greffer. Greffon generates the Django secret key, issues the certificate, and routes the app, so it comes up reachable over HTTPS without you assembling that plumbing by hand. You set an admin email and password at graft time, and that account is seeded on first start so you can log straight in.
Point your SDKs at it
Once GlitchTip is up, create a project in its web UI and it hands you a DSN: the URL your Sentry SDK sends events to. Drop that DSN into your app's Sentry config in place of the hosted one and your errors start flowing to your greffer instead. Nothing else about your instrumentation changes.
Because the SDKs send events over HTTPS, the same access story applies as for any web app. On the same network as your greffer it works the moment it starts. To ingest events from apps running elsewhere, you have two honest options: tunnel mode, where the greffer connects outbound and serves over HTTPS with no inbound ports opened (the answer for a box behind NAT or CGNAT), or exposing the greffer directly with port forwarding and DNS. GlitchTip is HTTP only, so the tunnel carries it without caveats.
Wire up alert email
Error tracking that cannot reach you is just a log file. GlitchTip sends alert notifications by email, and that needs an SMTP relay. The catalog entry exposes an SMTP setting and a default sender address, so point it at a provider you already have (or your own mail relay) and set the from address to something your provider will accept.
Memory and storage
GlitchTip is leaner than full Sentry, but it is still a Django web app with a background worker, a Postgres database, and Redis behind it. That is heavier than a single static container, so give it real headroom: a greffer with a fraction of a gigabyte of free memory will struggle, and a couple of gigabytes is a more comfortable floor once events start arriving.
Storage grows with the events you keep. A noisy app under a tight quota can fill a small disk faster than you expect, so set event retention to something sane for your volume rather than keeping everything forever, and keep an eye on disk on a small box.
Back it up
The history that makes error tracking useful (which errors are new, which are regressions, how often they fire) lives in the database. Greffon handles TLS and routing today, and native one-click backups are coming in M2. Until then, bring your own backup tool (restic or borgbackup are the usual choices), back up the GlitchTip data and database on a schedule, and store a copy off the greffer. If you only care about live alerting and not history, the cost of losing it is lower, but decide that on purpose rather than by accident.
Keep it always-on
Error tracking is only worth running if it is up when your apps break, which is exactly when you are not watching. Run it on an always-on greffer, a small VPS, or a mini-PC rather than a laptop that sleeps. If you need somewhere to start, a free Oracle Cloud box gives you a greffer with enough memory to host GlitchTip comfortably.
