Sentry self-hosted out of memory
Confirm dmesg OOM, then errors-only profile or leave to a small host.
On this pageShowHide
The container died because the host ran out of RAM. On Sentry self-host that is the expected result of a 2 GB or 4 GB VPS. The suite's own install docs ask for about 16 GB RAM plus 16 GB swap. A killed container is the box enforcing that floor.
Use this if
- Docker shows OOMKilled, or the process exited 137.
- dmesg or the kernel log says Out of memory.
- You installed Sentry self-host on a VPS that is not a 16 GB class machine.
Do not use this if
- You need the dated comparison essay. That essay is Sentry self-hosted RAM.
- You need a 512 MB scoreboard. That essay is What a 512 MB box can run.
- You need the Epure MiB table. That table is Resource footprint.
- Replay or tracing is how you debug. Stay on Sentry and give it the RAM.
Confirm it is memory
docker inspecton the dead container:OOMKilledtrue, often exit code 137.- Kernel log:
Out of memoryand the process name that was killed.dmesg -T | grep -i oomon the host (orjournalctl). - See which service died. Kafka, ClickHouse, Snuba, or the web container can be the one the kernel picked. The rest of the compose may still say Up.
- A Python traceback or a migration error is a different failure. Read that log before you buy RAM.
Why this install is heavy
Default self-host is errors plus traces, session replay, profiling, and the brokers under them. That is why the docs publish a 16 GB class machine and 20+ containers. From Sentry 24.8.0, COMPOSE_PROFILES=errors-only keeps issue-related services and drops traces, replays, and profiles. It does not become two containers. Disclose that profile before you argue footprint. Fair write-up: Sentry self-hosted RAM.
Stay on Sentry
- Move the compose to a host that meets their published RAM and swap.
- If you only wanted errors, set
COMPOSE_PROFILES=errors-onlyand measure again. Expect a smaller fleet, not a small VPS. - On Sentry Cloud, a heavy bill is a different problem: tracing left on, or a crash loop. Why the Sentry bill jumped.
Leave when exceptions are the job
A small VPS can run an exception tracker. It cannot run Sentry's suite. GlitchTip is MIT and about four services, with a 256 MB minimum and 512 MB recommended on their install docs. Bugsink is one container and SQLite, under Polyform Shield. Epure is Apache 2.0, two containers, PostgreSQL 16. Keep the Sentry SDK and change the DSN. Replay, tracing, profiling, and logs stay out of Epure. Shortlist: Best self-hosted error tracking. Matrix: Self-hosted research.
What Epure measured
Do not invent a new MiB number on this guide. Quote the dated full-stack rows on Resource footprint: about 53 MiB combined on the 2026-09-23 769 MiB VPS, about 82 MiB combined on 2026-09-12 Docker Desktop idle, plus the short ingest burst note. Those rows are not a promise your box will never OOM. Re-measure with docker stats on your metal before you quote a figure in an incident review.
If you cut the DSN over
- Stand up Epure.
GET /healthreturns ok. Installation. - Paste the DSN. Set trace, replay, and profile sample rates to 0. Migrate from Sentry.
- Send one exception. Expect HTTP 202, then one issue. Verify.
- Re-measure with
docker statson your metal before you quote a MiB number from memory.
The swap trap
Adding swap can keep containers alive on an undersized box while making every GC pause feel like a hang. Prefer sizing to Sentry's documented floors, enabling errors-only and measuring again, or leaving to a two-container errors host. Swap is a temporary bridge, not a sizing strategy for a 20+ container suite.
Which log first
Start with docker inspect for OOMKilled, then the kernel OOM line, then the dead service name. Buying a bigger box before you know which process the kernel picked is how teams pay for RAM they still misconfigure. Confirm memory first. Then stay, enable errors-only, or leave.