Sentry Self-Hosted

Last reviewed Sep 13, 2026 · 872 words

Every team I have watched adopt Sentry self-hosted has followed the same arc: install it in an afternoon, love it for six months, then discover during an upgrade that they are now the operators of Kafka, ClickHouse, PostgreSQL, Redis, and a couple of dozen supporting containers. Whether that ends well depends entirely on whether someone signed up for that. Sentry is the best error tracking software in existence, 44,721 stars and SDKs for every language you use; the self-hosted bundle gives you all of it, and the bill is paid in operations rather than dollars.

Start from the hardware number, not the feature list

The project's own requirements are 4 CPU cores, 16 GB of RAM and 20 GB of free disk, and the install script checks and complains below that. The 512 MB figure in the catalogue is what a single service in the stack idles at; the stack as a whole is the biggest thing most homelabs will ever run. On a 8 GB box it starts, then ClickHouse and Kafka fight for memory until something gets killed at 03:00. Give it a dedicated 16 GB VM or do not run it.

Installation itself is easy, which is the trap:

git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
./install.sh
docker compose up -d

Twenty minutes later there is a login page on port 9000, and the first user you create is the superuser. Put a reverse proxy with TLS in front, set system.url-prefix in sentry/config.yml to the public URL so emails and links resolve, and configure SMTP in the same file. It works beautifully at this point, which is why the six-month honeymoon happens.

Upgrades are the actual product you are buying into

Sentry releases monthly calendar-versioned builds and the self-hosted repo tracks them. You cannot skip arbitrary versions; the release notes name hard stops you must pass through in order, and each upgrade re-runs install.sh with a database migration that can take an hour on a busy instance. Skip 6 months and you are doing 3 sequential upgrades with a backup before each. Put the upgrade on a monthly calendar reminder, read the notes, and keep the previous compose directory until the new one has run a week.

Retention is the other lever. The default keeps events for 90 days, and a chatty frontend SDK can push millions of events a month; ClickHouse disk usage grows accordingly. Set SENTRY_EVENT_RETENTION_DAYS in the .env file to 30 before your first real project sends traffic, and use the per-project rate limits and SDK sample rates so a bug in a loop does not fill the disk at 02:00.

The licence is source-available, and that matters for one use case

The catalogue lists BUSL-1.1. In practice: you can run it for your own products, modify it, and pay nothing; you cannot offer it to others as a hosted error-tracking service. It converts to Apache-2.0 after the change date. For an internal tool at a company or a homelab, this changes nothing. For an agency thinking of reselling monitoring, it does. The open-source licence primer explains why this family of licences exists and what it is reacting to.

GlitchTip and Bugsink cover 80% of teams

GlitchTip accepts the same Sentry SDKs, runs on Postgres and Redis in 4 containers, and idles under 1 GB. It has error grouping, uptime checks and basic performance monitoring, and lacks Sentry's tracing depth, release health, and the polished issue workflow. Bugsink goes further in the minimal direction: one container, SQLite or Postgres, Sentry-SDK compatible, and content to be an error tracker only. If your question is "what crashed and where", either of those is the right first stop. Sentry self-hosted is for teams that use distributed tracing across services, profile performance, correlate errors to releases and deploys, and have someone on call for the platform. Pair whichever you choose with Uptime Kuma for the "is it up" question, which none of them answer well.

Sentry Cloud is cheaper than you think, for small teams

The hosted product's free tier handles a hobby project and the paid developer tier is about $26 per month at last check. Against a 16 GB VM, an afternoon a month of upgrades, and the on-call implications, self-hosting Sentry only wins on cost when event volume is large or data residency forbids the cloud. The Sentry alternatives page walks that arithmetic for the other direction.

What I'd do

Team under 10 engineers, or anyone whose stack is a homelab: run Bugsink or GlitchTip, send the same SDKs at it, and revisit if you outgrow it. Team with microservices, tracing needs, regulatory reasons to keep events on-premises, and an ops person: run Sentry self-hosted on a dedicated 16 GB VM, set retention to 30 days on day one, upgrade monthly with a backup, and treat it as the production database it is. Do not install it on the box that runs everything else. It will win.