The hidden cost of self-hosted Sentry (RAM + ops time).

The pitch vs the bill

The case for self-hosted Sentry has two parts: data sovereignty and cost. The data sovereignty argument is real and stands on its own. The cost argument depends almost entirely on how you count.

The software license is FSL-1.1-Apache-2.0 for Sentry itself; the self-hosted distribution is the open version of the same stack that runs Sentry’s cloud product. You do not pay per event. You do not pay per seat. The license is genuinely free.

From there, the pitch often stops. The bill continues. You pay for the compute that runs the stack, and the stack is not small. You pay for the storage that ClickHouse and Kafka consume over time, and that storage grows. You pay in engineer hours for the ongoing work of keeping the stack healthy, and those hours are real even when they come from someone who “handles infra anyway.”

The teams that arrive at a clean cost comparison run the full TCO: hardware, storage, ops time, and the implicit cost of downtime during upgrades. The teams that arrive at buyer’s remorse usually counted only the hardware and skipped the rest.

The RAM line item

The getsentry/self-hosted README documents a 16 GB RAM minimum. This number is real in the sense that the install script completes and the stack starts on a 16 GB host. It is not real in the sense of being a comfortable operating floor.

The stack is approximately twenty containers. ClickHouse, which Sentry uses as the time-series analytics backend for issues and performance data, is the largest single consumer. Under real ingest load it claims 8–12 GB on its own. Kafka and ZooKeeper together baseline at 2–4 GB; both run on the JVM and are sensitive to memory pressure in ways that produce non-obvious failure modes. Snuba (multiple workers), Symbolicator, Relay, Postgres, Redis, the web process, the worker, cron, and a handful of supporting consumers each add their share.

Operators on the getsentry/self-hosted issue tracker have documented this gap for years. Issue #3566 captures a common pattern: a 16 GB host running stably at idle, then Kafka and ClickHouse together consuming 14 GB after a week of real ingest, leaving no headroom for burst. The operator moved to 32 GB. Issue #1521 is a long-running hardware thread that spans 2022 through 2025; early replies suggest 8 GB, recent ones suggest 24–32 GB. The practical floor that experienced operators settle on is 32 GB.

What does a 32 GB VM actually cost in 2026?

Hetzner is the clear outlier on price. EU data residency and the Hetzner reliability track record make it a common choice for self-hosted Sentry operators who can use a European host. AWS on-demand is the expensive end; reserved pricing brings it closer to DigitalOcean. Add object storage for source maps and debug files (typically $5–20/month depending on volume), backup storage, and outbound transfer, and the infrastructure-only line item for a stable Sentry self-host lands in the $65–300/month range depending on provider and redundancy posture.

At $65/month (Hetzner, lightly redundant), annualized infrastructure cost is roughly $780/year. At $200/month (AWS, single-region), it is $2,400/year. That range is the hardware and storage floor, before a single minute of operator time.

The CPU and disk line items

The RAM floor dominates the initial sizing conversation. CPU and disk carry their own surprises after six months of real use.

ClickHouse stores Sentry’s time-series issue and performance data. It compresses well, but the raw ingest is not small. Teams report 20–50 GB of ClickHouse growth per month under moderate ingest. A year of data at moderate volume sits between 240 GB and 600 GB. The 240 GB SSD on a Hetzner CCX33 covers roughly 6–12 months of data before you either expand the volume or start pruning retention. Pruning is not automatic; it requires manual configuration of ClickHouse TTL policies, which most operators do not configure on day one.

Kafka retains event data on disk for a configurable window before consumers have processed it. The default log retention in the Sentry self-host Compose file is typically 48–72 hours. Under any meaningful ingest rate, Kafka’s data directory grows into the tens of gigabytes. Issue #2262 tracks the ClickHouse and Kafka disk growth pattern; the thread includes operators surprised to find 80–150 GB of Kafka data after a few months.

CPU pressure in the Sentry self-host stack is most visible during two operations: Symbolicator under load, and ClickHouse during a heavy Discover or performance query. Symbolicator downloads and processes debug information files for native crash symbolication. Each minidump from a large binary can spike CPU for several seconds. ClickHouse runs analytical queries against column-oriented data; a complex Discover query across months of data can peg two or three cores for several seconds. Neither of these is a showstopper on 8 vCPU, but both explain why 4 vCPU (the documented minimum) feels tight under concurrent use.

The practical CPU minimum for teams with more than one or two concurrent users is 8 vCPU. The disk minimum for a year of data at moderate ingest is 400–600 GB, which either means a larger root volume or an attached block device that someone has to provision and mount.

The ops time line item

The infrastructure has a sticker price. The ops time does not, which is why it is the most under-reported component of the Sentry self-host TCO.

Teams that track their time on self-hosted Sentry maintenance report 4–8 hours per quarter for routine upkeep. This includes: pulling updated Docker images and verifying the stack starts cleanly, monitoring ClickHouse and Kafka disk usage and trimming retention where needed, reviewing OOM events in the kernel log and adjusting container limits, investigating alert noise from the monitoring you run on your monitoring tool, and occasional container restarts when a JVM process has crept into a restart loop.

Four hours per quarter at a $150/hour all-in engineer cost (salary plus benefits, amortized) is $600/year. Eight hours per quarter is $1,200/year. That is the routine maintenance band.

Major version upgrades are a separate category. The install.sh script in getsentry/self-hosted pins container image versions. Minor updates generally apply cleanly. Major upgrades, particularly across Sentry releases that change ClickHouse schema or Kafka topic structure, have produced multi-hour to multi-day outages for teams who document the experience in the issue tracker. The upgrade instructions call for stopping the stack, running a migration, and restarting; in practice, teams report migrations that stall, container starts that fail with cryptic ClickHouse errors, and rollbacks that require restoring from a snapshot taken before the migration began.

If your team runs one major upgrade per year and it costs 8 hours on average, that is another $1,200 at $150/hour. If it goes badly and costs 2 days, that is $2,400 for one event. Teams that have been burned once by an upgrade tend to spend more time on the next one, which adds pre-migration testing time on top of the migration itself.

Incidents are the third category. When the tracker itself goes down, someone on your team is now debugging Kafka consumer lag and ClickHouse restart behavior instead of debugging the application errors that the tracker exists to surface. Incident response for the tracker is the ops cost that maps most directly to lost productivity, because it pulls an engineer away from product work at exactly the moment when you need observability most.

The range is wide because the inputs vary this much in practice. A team with an experienced SRE who has run Kafka before, hosting on Hetzner, with a clean upgrade history, can land near the low end. A startup team self-hosting on AWS because that is where their other infrastructure lives, with no prior Kafka experience, in a year with a rocky major upgrade, can land near the high end.

When it does pencil out

The math does favor self-hosted Sentry for a specific class of team. The conditions are concrete.

You already have an SRE team running similar infrastructure. If your team runs Kafka, Postgres, and Redis in production for other services, the marginal ops cost of adding Sentry to that stack is lower. The skills transfer. The alerting and monitoring tooling already exists. The upgrade discipline is already a habit. Teams in this situation can run the routine maintenance band much tighter than the $600–1,200/year estimate above.

You already have the hardware. If you operate a bare-metal cluster or a private cloud with spare capacity, the VM cost disappears. The remaining costs are storage, ops time, and licenses for any commercial components, none of which are large.

Data residency is a hard requirement. Some compliance regimes require that error and performance telemetry stay inside a specific geographic boundary or within a self-controlled environment. When a vendor-managed control plane is not an option, self-hosting is the correct answer regardless of cost. This is not a TCO calculation; it is a constraint.

You process more than roughly 50 million events per month. At this volume, a Sentry SaaS plan in the Business or Enterprise tier costs enough that the infrastructure and ops time of self-hosting become favorable even at AWS pricing. The cross-over point depends on your plan, your overage profile, and your ops cost, but teams above this volume should run the calculation explicitly. The model in the related guide (How to model your Sentry bill) provides the spreadsheet structure.

When it does not

The cases where self-hosted Sentry is the wrong choice are, in practice, the majority of teams who consider it.

Small teams where the operator is the team. If the person who would maintain the Sentry stack is also the person building the product, a ClickHouse restart at 11pm is not an infrastructure cost. It is a founder or lead engineer’s evening. That time is worth something specific and usually worth more than the difference between a SaaS bill and a Hetzner invoice.

Side projects and early-stage companies. The discipline required to run Sentry self-hosted safely (continuous backups, upgrade testing, alert triage, disk management) is the discipline of a mature ops practice. Building that discipline for a side project is a category error. The hardware cost of self-hosting is cheap; the overhead of doing it right is not.

Teams that have not priced their own time. The most common failure mode in self-hosted Sentry TCO calculations is treating ops time as zero because the work happens inside business hours and is absorbed into existing responsibilities. Time has a cost whether or not it appears on an invoice. An engineer who spends 2 hours on a Kafka restart is not spending 2 hours on the product. The opportunity cost is real even when the accounting does not capture it.

Teams with a Sentry SaaS bill under $3,000–5,000 per year. Below this range, the full TCO of self-hosted Sentry almost always exceeds the SaaS bill, even at Hetzner pricing and a clean upgrade history. The math only begins to favor self-hosting above this threshold, and only when the ops capacity exists to run the stack without significant marginal cost.

The alternative shape

The reason this TCO matters is that self-hosted Sentry is not the only self-hosted option. A different shape exists: one process, embedded database, no JVM, no orchestration layer.

urgentry is a Go single-binary Sentry-compatible tracker. SQLite is the default database; Postgres is optional for larger deployments. Under steady ingest at 400 events per second, the measured resident memory is roughly 52 MB. A $20–40/month VPS (4 vCPU, 4–8 GB RAM) is sufficient for most small and medium teams. The infrastructure-only cost annualizes to $240–480/year, a fraction of the Sentry self-host range.

urgentry covers 218 of 218 documented Sentry API operations. Errors, OTLP traces, OTLP logs, JavaScript source maps, ProGuard, native crash ingest, releases, alerts, and the issue lifecycle all work. Events from any Sentry SDK arrive without code changes; the migration is one DSN configuration line per service.

The gaps relative to Sentry are real and worth naming. Session replay is present with a partial playback experience rather than the full product surface Sentry provides. Deep profiling product surfaces (flamegraphs, continuous profiling) are narrower today. Multi-region high-availability is not the architecture. For teams where any of those are core to their workflow, Sentry self-hosted or Sentry SaaS is the correct answer.

For teams where the binding constraint is cost and the gaps are acceptable, the delta is significant: $240–480/year in infrastructure instead of $780–3,600/year, and a single binary with no JVM processes means the failure modes are simpler, upgrades are a binary swap, and the ops overhead is closer to 30 minutes per month than 4–8 hours per quarter.

This guide is published on urgentry.com, so treat the gap claims as ones to verify against the compatibility matrix before making a decision based on them.

How to actually run the comparison

The number you want is total cost of ownership on both sides of the ledger, annualized, with honest ops time included.

Start with your current Sentry SaaS bill. Pull the last three months of invoices from Settings > Billing. Take the average monthly cost. Multiply by 12. That is your annualized SaaS cost. If you are considering the move because the bill is growing, project it forward at the growth rate you have seen rather than using the current month.

Build the self-host side. The infrastructure component is the easy part: pick a provider, price the VM size you actually need (32 GB for Sentry self-hosted; 4–8 GB for a single-binary alternative), add storage and backup costs. The ops time component requires you to estimate honestly. How many hours per quarter would a first-time Sentry self-host operator in your team need for routine maintenance? How many hours for a major upgrade, given that you have not done one before? What is the cost of a three-hour incident at your team’s effective hourly rate?

A simplified TCO model:

The urgentry ops time estimates use 30 minutes per month for routine maintenance and 30–60 minutes per year for a binary upgrade (binary swap plus verify). The Sentry self-hosted estimates use the 4–8 hours per quarter and 8-hour major upgrade floor from the operator data cited earlier.

Fill in your team’s specific numbers: your actual engineer hourly cost, your cloud provider of choice, your realistic ops time estimate given your team’s background. The result tells you where the break-even is, and whether the product gaps in a simpler alternative are worth the cost delta.

Frequently asked questions