When error tracking is enough (no session replay, no APM)

Error tracking without session replay is enough when production fails and you need a grouped issue with a stack you can read, not a video of the session and not a distributed trace of every hop. If that is the daily job, a lite ingest host beats a full observability suite on the same invoice and the same VPS.

This note is the decision cut, not a roster and not an install runbook. For service count see Two-container error tracking. For dated RSS rows see Sentry self-hosted RAM. For the DSN swap path see Sentry SDK compatible and Migrate from Sentry. Product refusal of replay and APM sits on Welcome.

The job that fits

You ship a web or API product. An official Sentry SDK already lives in the app. When a deploy regresses, you open Issues, see the fingerprint, read frames, and ship a fix. Breadcrumbs help. Releases help. A webhook into chat or a tracker helps. You do not open a session replay to guess which button the user clicked, and you do not chase spans across five services before you know the exception type.

That loop is common on small teams. One person owns the SaaS and the Compose file. Metered traces and replay feel like a second incident when a crash loops overnight. The suite is correct for teams that debug with video and APM every day. It is oversized when the pager text is the stack.

• Fit: grouped exceptions, breadcrumbs, JS/TS sourcemaps, releases, webhooks, keyboard triage on a box you operate.
• Not fit: session replay as the primary repro tool, distributed tracing as the daily map, continuous profiling, native mobile symbolication depth.
• SDK path: keep @sentry/browser, @sentry/nextjs, @sentry/node, sentry-python, or a peer official client. Change dsn. Do not rewrite instrumentation for Honeybadger-style APIs unless you want that product.

Proof on the wire, not a brochure

Lite hosts that speak the Sentry envelope keep event items and discard or skip the rest. On Epure, envelope event items are parsed, queued, and persisted. transaction items are discarded because the product is error tracking, not APM. replay_*, profile*, session, attachment, and check_in are skipped. An envelope with no event item returns 400 invalid_envelope. Success is 202 Accepted plus { "id" }, then an unresolved Issues row (Envelope, Verify).

That keep/drop table is the honest answer to “without session replay.” Replay packets can still leave the browser if sample rates stay on. They do not become Issues on Epure. Set tracesSampleRate, replaysSessionSampleRate, and profilesSampleRate to 0 so you are not shipping volume nobody stores. Compatibility is partial: supported exception paths over DSN swap, not 100% Sentry protocol parity. Quickstart CI pins include @sentry/browser@7.120.0 and @sentry/node@7.120.0. Other runtimes are listed on Platforms. Sentry 8.x+ is not claimed as CI-proven here.

Footprint honesty when Sentry RAM enters the argument

Self-hosted Sentry’s published floor is high because the default product includes tracing, replay, profiling, and the brokers under them. As of 2026-09, comparisons on this site cite about 16 GB RAM, 16 GB swap, and 20+ containers (Sentry self-hosted). That warning is correct for that suite.

Fair disclosure: from Sentry 24.8.0+, self-hosted can set COMPOSE_PROFILES=errors-only. That profile keeps Issues, Alerts, Integrations, Dashboards, Releases, and Errors, and drops traces, replays, profiles, and related services (errors-only docs). Worth trying if you want to stay inside their stack. On a small VPS it was still more fleet than we wanted to operate. Epure stays two containers: Rust binary plus PostgreSQL 16, no Kafka, no ClickHouse, no Redis in the OSS compose (Installation).

Dated idle receipts, do not average rows. On 2026-09-23, classic Compose on a 2 vCPU / 769 MiB Linux VPS (Alibaba Cloud) measured about 5 MiB RSS for Epure and about 48 MiB RSS for Postgres with docker stats, about 53 MiB combined. A short store-ingest burst on that host, about 280-330 requests per second, kept Epure under about 12 MiB RSS. On 2026-09-12, a different Docker Desktop idle measured about 82 MiB combined for app plus Postgres. Neither row is a vendor minimum. Re-measure on the box you pay for (Sentry self-hosted RAM).

How you run the narrower path

Clone the public product repo, pin the image, bring up two services, hit health, create a project, paste the DSN. Laptop defaults publish host 8080 for the app and 5433 for Postgres. No .env is required for localhost. A real hostname needs the prod overlay under deploy/, real passwords, HTTPS in front, and EPURE_PUBLIC_URL set to https://… (Installation, Configuration).

EPURE_IMAGE=ghcr.io/epure-sh/epure:v0.1.3 docker compose up -d

curl -sS http://localhost:8080/health should return {"status":"ok"}. Open :8080, register, create a project, copy the DSN from setup or Settings. Point the official SDK at that DSN with traces, replay, and profiles sample rates at 0. Confirm with Verify: expect HTTP 202, then an Issues row. Empty Issues after 202 usually means env filter, wrong project, or worker flush, not “replay was required.”

Crash loops should raise the count without storing every duplicate body. Documented spike-valve defaults: about 100 raw events per minute per fingerprint (HTTP 202, counter rises, excess bodies drop), a project cap of 5000 events per hour (then HTTP 403 ingest_cap_exceeded), and a 2 MB body limit (HTTP 413 payload_too_large). Knobs may move before 1.0 (API Errors, Spike valve flood).

When the cut fails in practice

The decision fails in both directions. Teams leave Sentry and miss replay on day three. Teams keep the full suite on a $4 VPS and spend the week fighting Compose. Name the failure before you swap the DSN.

• You actually debug with replay. Support watches session video to reconstruct clicks. Dropping replay is not a RAM win, it is a lost tool. Stay on Sentry Cloud or another host that persists replay.
• You actually debug with traces. The bug only appears as a slow span across services. Lite error hosts discard transaction items. Stay on an APM product.
• You expected 100% wire parity. Sample rates at 0, then surprise empty Issues for a transaction-only envelope, or missing mobile native symbols. Epure is partial: exceptions and JS/TS maps, not a clone of Sentry Cloud.
• You left replay sample rates on. The browser still uploads replay payloads. The lite host skips them. You pay client bandwidth for nothing. Set rates to 0.
• You quoted RAM without naming the box. Mixing the 2026-09-12 Docker Desktop ~82 MiB idle with the 2026-09-23 VPS ~53 MiB idle into one “under 70 MiB” claim is fiction. Cite the dated row.
• You compared Epure’s two containers to Sentry’s full suite without mentioning COMPOSE_PROFILES=errors-only. Fair arguments disclose that profile, then note it is still a large fleet.

Peers and hard limits

GlitchTip, Bugsink, Telebugs, and Epure all cover the “errors without the suite” corner with different contracts. GlitchTip: MIT, about four containers, Postgres, long clock on the wire. Bugsink: one Django container, SQLite-first, Polyform Shield. Telebugs: $299 once, Rails + SQLite, 1 GB documented minimum. Epure: Apache 2.0, Rust + PostgreSQL 16, two containers, spike valve, dated idle RSS. Head-to-heads: vs Sentry, vs GlitchTip, vs Bugsink, vs Telebugs.

Hard limits on Epure, stated so you can leave: no distributed tracing product, no session replay product, no continuous profiling, no generic log ingestion, no iOS/Android symbolication depth (JS/TS .map only). Redis, Kafka, and ClickHouse are not required dependencies. Managed Cloud (Pro $24 for 200k events, Plus $79) is a separate hosted option with published prices; self-host license cost is $0 on Apache 2.0. The path here is the GitHub compose install, not a checkout flow (Pricing, Self-host).

Deep links: Quickstart | Verify | Installation | Envelope | Sentry self-hosted RAM.