Sentry Self-Hosting Runs 71 Containers. We Wanted One.

If you have never done it, go and clone Sentry's self-hosted repository and count the services defined in docker-compose.yml. It is a genuinely instructive exercise, and it takes about thirty seconds.

We counted 71. That figure assumes COMPOSE_PROFILES=feature-complete, which happens to be the value Sentry ships in its own .env file, so it is what you end up running if you follow the install guide and never go looking for ways to trim the stack down. Switching the profile to errors-only brings that number closer to thirty, but even the stripped-back version still expects you to operate Kafka, ClickHouse, Postgres, pgbouncer, Redis, memcached, three separate SeaweedFS services, Snuba along with its fleet of consumers, Symbolicator, Relay, a taskbroker, a taskworker, nginx, and an SMTP server. The official hardware requirements are 4 CPU cores, 16 GB of RAM plus another 16 GB of swap, and 20 GB of disk, with 32 GB of RAM recommended. There are open issues on the repository from people watching memory usage settle somewhere north of 22 GB and keep climbing.

None of this is a criticism of Sentry's engineering, and we want to be clear about that before going any further. Sentry built that architecture because they ingest a genuinely enormous volume of events on behalf of tens of thousands of organisations, and once you are operating at that scale, Kafka feeding ClickHouse is a perfectly sensible answer to the problem in front of you. If your event volume looks anything like Sentry's, you want Sentry's architecture, and you can stop reading here.

The trouble is that most of us are nowhere near Sentry's scale, and we have spent the last few years pretending otherwise.

The problem we actually had

We manage infrastructure for clients spread across roughly ten countries, and the shape of a typical environment is not exotic. There is a Laravel application, a Postgres or MariaDB behind it, nginx in front, possibly a Redis, all running on a handful of servers. Error volume is measured in thousands per month rather than millions per second, and the same is true of almost every team we talk to.

For years, the realistic options broke down like this.

You could use Sentry SaaS, which works well and lets you pick an EU region at no extra cost. The friction there is the billing model rather than the product: when a bad deploy throws half a million duplicate errors at three in the morning, that spike arrives as a line item on your invoice rather than as a counter that quietly stops.

You could self-host Sentry, at which point you are running seventy-odd containers and a Kafka cluster in order to catch a few thousand stack traces a month. We have done this for clients, and the pattern that emerges is reliably grim: the monitoring stack becomes the least reliable component in the entire environment, which is a special kind of irony when the whole point of it was to tell you when things break.

You could run GlitchTip, which is a genuinely good project and much lighter than Sentry, needing only Django, Celery, Redis, and Postgres. Four moving parts instead of seventy is a serious improvement, and it covers error tracking, performance monitoring, uptime monitoring, and cron monitoring. If what you want today is an open source server that speaks the Sentry protocol, it is a real option and we would recommend it without any embarrassment.

Or you could run nothing at all, which is what a depressing number of teams quietly settle for, and which means they learn about their errors from customers rather than from their tooling.

What we wanted was something shaped like the problem we actually had: solid error tracking for small and medium teams, hosted in the EU, that a single person could run on a cheap box without gradually becoming a part-time Kafka operator. Since that did not appear to exist, we built Tindra.

One binary and a Postgres

Tindra is a single Go binary, and it needs a Postgres. That is the entire dependency list, and the install reflects it.

bash -c "$(curl -sSL https://install.tindra.sh)"

There is no Kafka, no ClickHouse, no message broker, no separate search cluster, and no sidecar quietly waiting to fall over at three in the morning and take ingestion down with it. You pull the image, point it at a Postgres, and it runs.

The trade-off is real, and we would rather name it ourselves than have somebody discover it later: this design will never ingest a million events per second, because it is not trying to. It is built for teams whose error volume fits comfortably inside Postgres, and that description covers a great many more teams than the industry's prevailing architecture choices would lead you to believe.

Your existing SDKs already work

Tindra implements the Sentry ingest protocol, which means every Sentry SDK works against it without modification, whether you are running Laravel, Vue, Go, Python, Rust, Node, something in the browser, or something on a phone.

Migration is a single line of configuration.

// .env
SENTRY_LARAVEL_DSN=https://your-key@your-tindra-instance/1

You change the DSN, you deploy, and you are done. There is no SDK to swap out, no code to rewrite, and nothing to re-instrument. Equally, if Tindra turns out not to suit you, changing that line back is just as cheap, and we think that is the right way to earn a migration: make leaving trivial, then be worth staying for.

What you get

The product covers errors with full stack traces and grouping, performance monitoring with span waterfalls and a highlighted critical path, HTTP uptime probes, cron monitor health so that you find out when the nightly job silently stopped running, and a log viewer. Alerts are configurable across all of it.

There is also an MCP server built in, so you can ask Claude or Cursor about your open issues, your slowest endpoints, and the health of your cron jobs without leaving the editor. Write access is opt-in on a per-token basis.

On that last point we should be straight with you, because the comparison tables floating around this category are not always careful: Sentry has an official MCP server too, hosted at mcp.sentry.dev, and it exposes more tools than ours does. The distinction is architectural rather than existential. Sentry's MCP is a separate hosted service that you point at your instance, whereas ours is compiled into the binary that is already running, which means self-hosted users get it with nothing additional to deploy and it behaves identically whether you run Tindra yourself or let us run it for you.

Run it yourself, or let us run it

The binary is source-available under the Elastic License v3, and you can self-host it with no telemetry, no license server, and nothing counting your seats. Support happens through GitHub Issues and Discussions.

Licensing deserves an honest footnote, because it is the one place where a competitor has a cleaner story than we do. Sentry uses the FSL, which converts to Apache 2.0 after two years, whereas the Elastic License v3 does not convert to anything. Neither license is OSI-approved open source, and if a properly open source license is a hard requirement on your side, then GlitchTip is simply the better answer and we would rather tell you that now than waste a week of your evaluation.

If you would prefer not to run it at all, we offer managed instances starting at $9 a month, and every managed customer gets a dedicated container and a dedicated Postgres. Not a row in a shared table, not a schema-per-tenant arrangement, but its own process with its own database. Managed plans also include nightly encrypted backups, fourteen-day point-in-time recovery, and a signed DPA.

The EU question, argued properly

Before we make the argument we actually believe, let us dispose of a lazy talking point that shows up constantly in this category: Sentry does offer EU data residency, on every plan including the free one, and it costs nothing extra. You choose between US and EU (Germany) when you create the organisation, the choice is permanent, and the EU region lives at de.sentry.io. Anyone still telling you that European hosting is a Sentry upsell has not checked since 2023.

So the real question was never whether you can keep your data in Europe. It is what sits behind the region you selected.

Sentry is an American company and Blendbyte is a German GmbH. Data sitting in a Frankfurt data centre operated by a US-owned provider remains reachable under American law, which is precisely why the CLOUD Act keeps surfacing in European procurement reviews and why Schrems II turned on corporate structure rather than on the physical location of the disks. If your compliance team has ever asked who ultimately controls a given dataset, picking a region does not answer that question, whereas corporate domicile does.

Tindra Managed runs entirely within the EU, operated by an EU company, with no US sub-processors anywhere in the chain. Backups replicate to a second availability zone inside the same region, object storage never leaves the EU, and you get a signed DPA under GDPR Article 28 along with data deletion within 24 hours.

Whether any of that matters to you depends entirely on who audits you, and we are not going to pretend otherwise. For a great many teams, Sentry's EU region is genuinely sufficient, and choosing us over them on residency grounds alone would be cargo-culting compliance. For teams in regulated industries, in the public sector, or anywhere a procurement lawyer has already said the words "CLOUD Act" out loud, it tends to be the entire conversation.

There is a separate problem lurking underneath all of this that almost nobody writes about, which is that stack traces are personal data far more often than people assume. The local variables captured in a frame routinely contain email addresses, session tokens, and the full body of whatever request just exploded, and that remains true no matter which region you ticked. We will dig into that properly in a few weeks.

Pricing, and what happens when you hit the ceiling

Events are errors and transactions combined, yearly billing saves 10%, and there is a fourteen-day trial that does not ask for a card.

The behaviour we care most about is what happens at the limit, because this is where monitoring bills tend to get interesting. When you hit your event ceiling, recording pauses until the next cycle and you are not billed for the overage. If a deploy goes badly wrong at two in the morning and throws four hundred thousand duplicate errors, your invoice looks exactly the same as it did the day before. You can upgrade if you want more headroom, but that decision stays yours rather than being made retroactively by a billing system.

How it actually compares

Everything below was verified in July 2026. If we have got something wrong, tell us and we will correct it.

Sentry wins comfortably on breadth, and it is not close. Session replay, profiling, mobile symbolication, Seer, and an integration catalogue we are not going to match this year all sit on their side of the table, alongside a free tier, EU hosting, and a log product with a more generous included allowance than ours. If you need any of that then use Sentry, and if your scale makes seventy containers a proportionate amount of infrastructure, self-host it with our blessing.

GlitchTip wins on licensing, and it is not particularly close there either. MIT, properly open source, four containers, and a free-forever tier. If your requirements document contains the phrase "OSI-approved," you have already found your answer.

AppSignal is a solid managed product from a Dutch company, and a reasonable choice if you have no interest in self-hosting anything.

Our own case is narrower than any of those, and we would rather state it precisely than oversell it. Tindra is the right choice if you want one container to self-host, an EU company rather than merely an EU region, billing that pauses instead of charging, and an MCP server already running inside the process you deployed. If those four things describe your situation, we think we are the best fit available. If they do not, one of the three products above almost certainly is.

Who should not use this

If you are ingesting tens of millions of events a month, our architecture is the wrong shape for your problem, and claiming otherwise would only waste both our time.

If session replay or profiling is load-bearing in how your team debugs, we do not have either of those yet.

If you need an OSI-approved license, use GlitchTip.

And if you are already on Sentry SaaS, it is working, and nobody in your organisation is asking questions about data residency, then stay where you are. Migrating a monitoring stack for its own sake is a poor use of a sprint.

Try it

You can self-host it and see for yourself:

bash -c "$(curl -sSL https://install.tindra.sh)"

Alternatively, start a trial, which runs for fourteen days and does not ask for a card. Point a single DSN at it and see what your errors look like on the other side.

We run Tindra in production for our own infrastructure and for our clients, which is less a testimonial than an explanation of why it exists at all. We wanted good error tracking that would run on a small box and be operated by a company in the same legal jurisdiction as the clients whose data it holds, and nothing on the market did both.

Want us to run your monitoring?

Monitoring sits inside what we already do under our server management and retainer packages, whether that means Tindra, Sentry, or the Prometheus stack you have been quietly ignoring for two years. If you would like a second opinion on your observability setup, talk to us. The first thirty minutes are free.