Sentry's usage-based pricing works fine until your team starts shipping more releases, wiring up more services, and watching event counts climb every sprint. At that point a lot of engineering teams start pricing out self-hosted error tracking, and GlitchTip — the open-source, Sentry-compatible error tracker — is usually the first stop. This is a sizing and setup guide for running GlitchTip on a self-hosted error tracking VPS: what the stack actually needs, how to size it against your event volume, and where the EU-jurisdiction angle matters if your error payloads carry user data.
Why Teams Move Error Tracking Off SaaS
Two things usually trigger the move. First, per-event billing scales badly once you add source maps, session replay hooks, or a second and third service reporting into the same project — the invoice grows faster than the value you're getting out of it. Second, and less talked about, stack traces and breadcrumbs routinely capture request payloads, headers, query params, and sometimes user identifiers. That's application error data with PII in it, sitting on infrastructure you don't control, in a jurisdiction you didn't necessarily choose.
Self-hosting doesn't just cut the bill — it puts you back in control of where that data lives and who can query it. That's the whole case for a self-hosted error tracking VPS: same Sentry SDK your apps already use, different (and chosen) place for the data to land.
GlitchTip vs Sentry: What You Get Self-Hosted
GlitchTip speaks the Sentry protocol, so your existing Sentry SDKs (Python, Node, Go, Ruby, PHP, mobile, whatever) point at your GlitchTip DSN with no code changes. You get issue grouping, alerting, releases, and performance basics. You don't get Sentry's full session replay or some of the newer SaaS-only features — GlitchTip is deliberately a leaner, self-hostable subset. For teams whose actual daily workflow is "catch the exception, group it, alert the on-call, link it to a release," that subset is usually the whole job.
As a sentry alternative self-hosted setup, GlitchTip's own footprint is modest: a Django-based web app, a Celery-style worker for processing events asynchronously, Postgres as the event store, and Redis as the queue/cache layer. That's the stack you're sizing a VPS for.
Sizing a Self-Hosted Error Tracking VPS
GlitchTip's components are lightweight individually, but Postgres is where sizing actually matters — event volume and retention window drive disk and RAM needs more than anything else. Here's how we'd map it against a hosting tier lineup that runs EUR4 to EUR58/mo:
| Tier | Specs | Price | Good fit for |
|---|---|---|---|
| VPS I | 2GB RAM / 1 vCPU / 40GB NVMe | EUR4/mo (EUR0.0056/hr) | Single small app, low-traffic staging environment, evaluating GlitchTip before committing |
| VPS II | 4GB RAM / 2 vCPU / 80GB NVMe | EUR6/mo | One production service plus staging, small team's default error tracker |
| VPS III | 8GB RAM / 2 vCPU / 120GB NVMe | EUR10/mo | Several services reporting in, room for Postgres to grow without swapping |
| VPS IV | 8GB RAM / 2 vCPU / 120GB NVMe | EUR16/mo | Same footprint as III with more CPU headroom for the worker under bursty error spikes |
| VPS V | 16GB RAM / 4 vCPU / 200GB NVMe | EUR30/mo | Multi-team org, longer retention windows, Postgres and Redis on separate volumes |
| VPS VI | 32GB RAM / 6 vCPU / 400GB NVMe | EUR58/mo | Highest ingestion volume before you'd consider splitting the DB onto its own box |
Start one tier lower than you think you need — GlitchTip's Docker Compose stack resizes cleanly, and root SSH access means bumping RAM/CPU on the same disk is a resize-and-reboot, not a migration.
The Docker Compose Stack, in Practice
GlitchTip ships an official Docker Compose file with four services: postgres, redis, web (the Django app), and worker (event processing). Root access is what makes this straightforward on a VPS — install Docker and Compose, drop in the compose file and an env file with your secret key, database URL, and mail settings, and bring it up. No platform-specific quirks to work around, no shared-hosting restrictions on background workers or long-running processes.
A few things worth planning for before you go live:
- Put Postgres data on a volume mounted to NVMe-backed storage — the event store is write-heavy and NVMe keeps ingestion from becoming the bottleneck.
- Set a retention/cleanup policy early. GlitchTip doesn't need to keep every event forever, and disk fills up faster than you'd expect once several projects are reporting.
- Put GlitchTip behind a reverse proxy (Nginx or Caddy) with TLS — your SDKs are sending exception data over the wire and it should be encrypted end to end, not just at rest.
- Size outbound bandwidth for burst ingestion. A bad deploy that starts throwing exceptions across every instance can spike event volume for a few minutes, and 1 Gbps unmetered symmetric bandwidth means you're not throttled or billed extra when that happens.
Keeping Error Payloads Under EU Jurisdiction
This is the part that doesn't show up in a feature comparison table but matters a lot once legal or a customer asks where error data lives. Stack traces routinely include request bodies, auth headers, and sometimes raw user input — data that counts as personal data under GDPR the moment it includes an email, IP, or user ID. Running GlitchTip on EU-based infrastructure means that data never leaves EU jurisdiction as a matter of architecture, not a checkbox in a vendor's compliance page you have to take on faith. If GDPR posture is part of why you're evaluating this move at all, it's worth reading through our GDPR-compliant hosting use case alongside the sizing above.
When to Move Off a VPS Entirely
A single self-hosted error tracking VPS runs GlitchTip comfortably up through VPS VI's 32GB/6vCPU/400GB envelope. Past that — multiple business units, compliance requiring physically isolated hardware, or Postgres growing large enough that you want it on its own machine separate from the web/worker tier — that's when it makes sense to split the stack across a small cluster or move the database tier onto a dedicated server. Most teams never need to make that jump; it's worth knowing the ceiling exists before you hit it mid-incident.
How Noded Can Help
We run VPS I through VPS VI on our own network — NVMe storage, root SSH from the first boot, and 1 Gbps unmetered symmetric bandwidth on every tier, so there's no separate "ingestion bandwidth" add-on to negotiate. Deploys come up in a median of 47 seconds, so testing GlitchTip's Docker Compose stack on a VPS II or III before you commit is a same-afternoon exercise, not a procurement cycle. If you outgrow the VPS tiers, our dedicated line is the next step without moving providers. Check current specs and pricing on our VPS hosting page.
FAQ
What size VPS do I need to self-host GlitchTip?
For a small team or a single production service, VPS II (4GB/2vCPU/80GB, EUR6/mo) is usually enough to run web, worker, Postgres, and Redis together. Multiple services or longer retention windows push that up to VPS III or IV (8GB/120GB); go with VPS V or VI if you're running several teams' projects through one instance.
Is GlitchTip a real replacement for Sentry?
For issue tracking, grouping, alerting, and release tracking driven by the standard Sentry SDKs, yes — that's the core workflow most teams use daily. It doesn't replicate every SaaS-only Sentry feature (like full session replay), so check your team's actual usage against GlitchTip's feature set before migrating.
Does self-hosting error tracking actually help with GDPR compliance?
It gives you architectural control over where error payloads — which can contain personal data — physically live, which is a meaningful part of a GDPR posture. It's not a substitute for your own data processing agreements and internal handling policies; see our GDPR-compliant hosting page for how that fits together.
Can I run Postgres, Redis, and GlitchTip on the same VPS?
Yes, and for most teams that's exactly how it should run — GlitchTip's official Docker Compose file is built for a single-host deployment. Just put the Postgres volume on NVMe-backed storage, since that's where sizing pressure shows up first as event volume grows.
What happens when I outgrow a single VPS?
Split the database tier onto its own instance, or move to a dedicated server if you need isolated hardware for compliance or scale. Most self-hosted GlitchTip deployments never need to go past a single higher-tier VPS, but the option is there.