Sentry self-hosted RAM vs Epure: 5 MiB plus 48 MiB idle on a 769 MiB VPS

Sentry self-hosted RAM is the reason many small teams stop self-hosting Sentry: its requirements page asks for 4 cores, 16 GB of RAM plus 16 GB of swap and 20 GB of disk (checked 6 Nov 2026). We wanted to know what Epure uses on the kind of server a solo founder rents. On 23 Sep 2026 we started Epure and Postgres 16 on a 2 vCPU VPS with 769 MiB of RAM and read the containers at rest.

About 5 MiB plus 48 MiB is far below 512 MB, which is why this URL says so. The honest reading is narrower: two idle containers fit in a fraction of a small VPS. Whether Epure serves your traffic on a 512 MB host is a different question, and this page does not answer it.

How much RAM does self-hosted Sentry need?

Self-hosted Sentry needs at least 16 GB of RAM plus 16 GB of swap, and Sentry recommends 32 GB (self-hosted docs, checked 6 Nov 2026). The figure follows from the architecture: release 26.10.1 defines 53 Compose services by default, and 28 with COMPOSE_PROFILES=errors-only, Kafka and ClickHouse included. That is a published minimum for a whole platform under load, not a measurement, so it does not compare directly with an idle reading.

The two numbers answer different questions. Sentry's says what the vendor supports for errors, tracing, replay and profiling together. Ours says what two containers hold in memory before the first event arrives. Read them as an order of magnitude, and see self-hosted error tracking compared for the other lightweight options and their own published minimums.

What machine did we measure Epure on?

Our test host was a 2 vCPU Intel Xeon VPS with 769 MiB of RAM and 4 GiB of swap, running CentOS 8 (kernel 4.18) on Alibaba Cloud, measured on 23 Sep 2026. Epure ran from the repository's root docker-compose.yml: the ghcr.io/epure-sh/epure:latest image of that day and postgres:16-alpine. The box also ran the Docker daemon, Tailscale, the provider's monitoring agent and Glances 3.3.1 for screenshots, so the containers shared it with other processes.

That last detail matters for anyone sizing a host. The free -m output below shows 348 MiB used on the whole machine at the first idle sample, most of it outside the two containers. On your server the operating system, a reverse proxy and your own app sit in the same memory.

How did we measure Epure's idle memory?

We measured Epure's idle memory with docker stats --no-stream for the two containers, free -m for the host and uptime for load, taken by one shell script into a timestamped text file. The first sample ran at 18:07:54 UTC on 23 Sep 2026 with Epure up and no events arriving, and a second one 19 seconds later. You can repeat it on your own server with three commands.

git clone https://github.com/epure-sh/epure.git && cd epure
docker compose up -d
# wait until /health answers, send nothing, then:
docker stats --no-stream
free -m

Our raw idle sample, trimmed to the lines that matter:

=== label=idle ts=2026-09-23T18:07:54Z ===
-- free -m --
              total        used        free      shared  buff/cache   available
Mem:            769         348          52          16         369         282
Swap:          4095          58        4037
-- docker stats --
NAME               CPU %     MEM USAGE / LIMIT     MEM %
epure-epure-1      0.01%     5.344MiB / 769.6MiB   0.69%
epure-postgres-1   7.21%     48.04MiB / 769.6MiB   6.24%

Does a 5 MiB plus 48 MiB idle reading mean Epure runs on a 512 MB server?

No, an idle reading of about 5 MiB plus 48 MiB does not show that Epure handles production traffic on a 512 MB server. Memory grows with ingest, with the Postgres cache as the database fills, and with source-map processing for JS/TS releases. We have not published an ingest capacity for Epure, and nothing on this page should be read as one.

We did send a few short bursts of test events on the same box that evening. We are not publishing throughput or burst memory from them. The load generator ran on the same 2 vCPUs as Epure, each burst lasted under 3 seconds, there was one sample per burst, and Glances itself grew to use much of the spare memory. Those are smoke tests, not a benchmark. Postgres, not Epure, was the larger and busier container throughout.

To size a real host, run the same commands under your own traffic for a day, with your retention and your source maps, and keep headroom for a pg_dump and an upgrade. The installation guide covers the production overlay with HTTPS, and Epure upgrades shows the backup and rollback steps.

Where do other self-hosted error trackers beat Epure on footprint?

Other lightweight trackers publish things we have not. GlitchTip documents a 256 MB minimum in all-in-one mode and recommends 512 MB (GlitchTip install docs, checked 6 Nov 2026). Telebugs publishes a throughput figure on 2 vCPU and 4 GB (Telebugs). Rustrak's README reports a peak under 60 MB during a 20,000-event burst on 4 cores (Rustrak). We have not reproduced any of these.

• One container instead of two. Bugsink, Telebugs and Rustrak run as a single container on SQLite. Epure needs a Postgres 16 container next to it, and Postgres used most of the memory we measured.
• A published minimum. GlitchTip and Telebugs state one. Epure states an idle measurement only.
• Load numbers. Telebugs and Rustrak publish figures under load. Epure does not, yet.
• Scope for the RAM. Self-hosted Sentry spends its 16 GB on tracing, replay, profiling and native symbolication, none of which Epure does.

Should you self-host Epure on a small VPS or use Epure Cloud?

Self-hosting Epure on a small VPS makes sense when someone on the team will own backups, upgrades and disk growth: the engine is AGPL-3.0, with no event quota and unlimited seats. Epure Cloud makes sense when nobody will: Pro is $29 a month for 200,000 events, and once your team is admitted it starts with a 14-day trial, no card (Epure pricing). Either way the Sentry SDK stays and only the DSN changes.

Where is the raw data, and what changed since the first run?

The raw data for this receipt is 27 text files: host details, both idle samples, and a sample, result and log for each burst, plus 5 Glances screenshots. The idle lines above are copied from them unedited. If you want the full set, open an issue on epure-sh/epure and ask for it, or email support@news.epure.sh to report a mistake.

• 23 Sep 2026: measured on the latest image of the day v0.1.0 shipped.
• 6 Nov 2026: page rewritten around the raw readings and the limits. Numbers unchanged. Not yet re-run on v0.2.0, which added durable ingestion; until it is, treat these figures as v0.1.0 figures.