Sentry alternatives wey no go chop 16 GB RAM

Wetín self-hosted error tracking go cost before e store one event

Self-hosted error tracking get one number wey dey decide the whole choice: na RAM floor. Sentry own self-hosted documentation ask for 4 CPU cores, 16 GB of RAM plus 16 GB of swap, and 20 GB of free disk, before your application send even one event. GlitchTip document 512 MB. All the options here accept events from the same Sentry SDKs, so this no be decision about how you instrument your code. Na decision about how big server you ready to pay for and keep running.

Resource figures wey each project publish, side by side

These na the numbers wey each project publish about itself, as of August 2026. Dem no measure the same thing, so read the note for each row before you compare dem.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Sentry's 16 GB na documented minimum, and the same page recommend 32 GB. GlitchTip's 0.5 GB na recommendation, and the project talk say 256 MB na workable minimum, or 128 MB plus swap if you configure am carefully. Bugsink's 4 GB no be either of those: na the box wey the vendor use for im own throughput benchmark. Any published figure na starting point; e no promise say e go handle your event volume.

Sentry self-hosted: the complete product, and the complete bill

The official stack na getsentry/self-hosted, a Docker Compose project wey dey run the same components Sentry dey run for production. The documentation describe am as "feature-complete and packaged up for low-volume deployments and proofs-of-concept". That sentence na the honest summary. You go get every feature, and you go get every moving part wey those features need to work.

Install from a tagged release instead of from master:

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

Then start am:

docker compose up --wait

Sentry dey listen on http://127.0.0.1:9000 by default. Docker Engine 19.03.6 or later and Docker Compose 2.32.2 or later dey required, and older Compose go fail because of the file syntax, not because of anything Sentry do.

Check wetin you actually start:

docker compose ps
free -h

docker compose ps list every service for the stack, and the list long: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, plus several worker and cron processes. Count dem once, because that number na your maintenance load. Every entry na process wey fit crash, fill disk, or fail migration.

If service remain for Restarting state, check memory before anything else:

dmesg -T | grep -i 'out of memory'

A line like Out of memory: Killed process 3412 (java) mean say the kernel OOM killer (out of memory killer) kill one container because the machine run out of RAM. Because of that, the service no become healthy and the stack no finish starting. This na the normal result when you run the full stack below the documented minimum. The documentation also warn about disk speed: iowait above 10% mean say the machine no fit keep up with the ingest pipeline. Read am from the wa column inside top, or from iostat -x 5 if you get sysstat installed.

Upgrades na the part wey people dey underestimate

Sentry self-hosted releases every month under CalVer, a calendar-based version scheme, with the main release on the 15th of every month. You no fit jump from old version straight to the latest one. The project define hard stop versions, and you must check out each one in order so e fit apply the database migrations. As of August 2026, the published hard stops na 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 and 26.7.0. The documentation also list releases to skip because of migration problems, including 23.7.0, 25.9.0, 25.12.0 and the 26.3.0 to 26.4.0 range.

Upgrade na checkout plus rerun of the installer:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

Take a snapshot of the server before you start, because migration over a large ClickHouse dataset fit run for hours, and failure halfway fit leave the database between two schemas. The straightforward reason why most self-hosted Sentry upgrades fail: the machine stay on one version for one year, so the jump cross several hard stops at once, and one of the skipped migrations na the one wey matter.

You need know one more thing before you commit. Sentry self-hosted dey under the Functional Source License (FSL), wey Sentry introduce by itself. E be fair source, not OSI-approved open source: you fit run am for yourself, but you no fit sell am as a competing service. Each release go convert to Apache 2.0 two years after e release.

GlitchTip: 512 MB answer

GlitchTip get MIT license, and e dey receive events from Sentry open source SDKs. So, to move one instrumented application go am, na to change one value: the DSN (data source name, the URL wey your SDK dey post events to). E need PostgreSQL 14 or later. Valkey or Redis 7 or later optional, and e dey make bigger instances faster.

Installation na Docker plus one compose file:

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

Edit the environment section before you start anything. The values wey you must set na the secret, the domain, and the mail path:

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

The sample don already connect DATABASE_URL to its own postgres service, so leave that line as e be unless you dey point am to database wey you run elsewhere. GLITCHTIP_DOMAIN must include the scheme. If https:// no dey for the front, the links inside alert emails go build wrong and land for URL wey no dey respond.

Start am and monitor the first boot:

docker compose up -d
docker compose logs -f web

The image tags for the sample as of August 2026 na postgres:18, valkey/valkey:9 and glitchtip/glitchtip:6. Keep dem pinned. If compose file talk say latest, e go upgrade your database engine for the next docker compose pull, and Postgres major version jump under running instance na how working error tracker go stop starting.

To reach 256 MB to 512 MB range, the comments inside the sample file tell you wetin to switch off, starting with Valkey and the optional log and uptime features. If you run without Valkey, GlitchTip go use its database for cache and queue work instead. This one slower, but e still correct. All in one mode dey run the worker inside the web process, so you go maintain one application container instead of two.

Put proxy for front of am. GlitchTip documentation ask for proxy or load balancer wey dey buffer requests and handle chunked Transfer-Encoding, and e use nginx as the worked example. Without buffering, slow client go hold application worker open for the whole upload. So, some slow senders fit occupy every worker wey you get, and healthy clients go start timing out.

Upgrades na the easy part:

docker compose pull
docker compose stop
docker compose up -d

Database migrations dey run automatically when e start. Still take dump first, because automatic migration still be migration.

Bugsink: wan container, and licence wey you must read

Bugsink na the lightest one for the three. E dey speak Sentry SDK protocol, and e dey run without message queue or any external service apart from database. SQLite na the default, while e support MySQL and PostgreSQL when the setup pass wetin SQLite fit handle.

Use temporary instance to check the interface before you commit:

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Open http://localhost:8000/ and sign in with the address and password wey you pass for CREATE_SUPERUSER. That container no dey keep anything when e stop. For real instance, use the project's compose sample. E pair bugsink/bugsink:2 with postgres:17-alpine and set DATABASE_URL, BASE_URL and BEHIND_HTTPS_PROXY. Generate the secret the correct way:

openssl rand -base64 50

BASE_URL must match the URL wey your users and SDKs really dey use, including the scheme. If you leave am as http://localhost:8000 for a machine wey you reach through https://errors.example.com, every link for notification email go point to host wey the person reading am no fit resolve. Set BEHIND_HTTPS_PROXY to true when nginx or Caddy dey terminate TLS (transport layer security) in front of am. If you no do this, Bugsink go build http:// URLs behind your https:// proxy, and browsers go block the mixed content.

The vendor publishes its own throughput figures: 18 events per second at 50 KB each. This works out to 1.5 million events per day on a 2 vCPU and 4 GB VPS. Treat this as an indication of the tool's capacity, not a guarantee for your workload. E still show say the ceiling dey far above wetin one small application dey produce.

Now na the licence, and you need read this part before you put am for your stack. Bugsink dey released under PolyForm Shield License 1.0.0. This means the source dey available, but e no be open source: you fit run am and modify am, but you no fit use am build something wey dey compete with Bugsink. For internal error tracker, this restriction no go affect you. If your company dey sell developer tooling, make somebody read the licence text first.

Error tracking and LLM observability na still two different tools

Search for one tool wey fit do error tracking and large language model (LLM) observability together, and you go see products wey claim say dem fit do both. The data structure no be the same, na why the merger never really work. Error tracker dey receive exception with stack trace, calculate fingerprint from am, then group thousands of occurrences into one issue with counter. LLM tracing tool dey receive span wey hold prompt, response, token count, and latency. E must keep every one of dem, because two calls with identical inputs still be separate events wey worth reading.

So run both. Send exceptions go error tracker, and send model calls go somewhere wey dem build for that purpose: self-hosted Langfuse for agent tracing cover that side, while self-hosted AI observability approach the same work from another angle. Your application already dey produce both kinds of failure. Model call wey return confident nonsense no throw any exception, so error tracker no go ever show am to you.

Disk growth na the failure wey go find you later

Every error tracker na write-heavy database with input wey no get limit. Your application dey decide how much e writes, and one new bug for code path wey dey run often fit produce one million events overnight.

GlitchTip publishes one figure wey worth using for planning: instance wey dey handle one million events per month fit need 30 GB disk space. This covers one month of ingest for that rate, and your retention window go decide how many months you dey store at the same time.

Bugsink dey handle am from the other side. Instead of fixed quota, e applies retention algorithm based on event count and event age, and e exposes the caps directly: MAX_RETENTION_EVENT_COUNT for the whole installation, MAX_RETENTION_PER_PROJECT_EVENT_COUNT per project, and MAX_EVENT_AGE_DAYS as absolute cut-off. Setting installation-wide event budget na the honest way to size disk, because that budget na the disk.

Monitor the real numbers for the server:

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v prints size for each volume, so you fit see which service dey grow. If volume dey gain several gigabytes every week without any change for traffic, e usually means say retention never configure. That means nothing dey delete, and the only limit na the partition.

Memory na the same problem with different appearance. Stack wey no get limits go take everything wey kernel offer, and when machine run out, OOM killer go choose the biggest process. That process fit be your web server instead of the tracker wey cause the problem. Give every service a limit: memory limits for Docker Compose shows the syntax and wetin container dey do when e reach im cap. Container wey system kill at im own limit na contained failure. Container wey kernel kill fit carry neighbour service down with am.

Which stack fit which VPS

• 1 GB, or 2 GB with room to spare: GlitchTip for all in one mode with Valkey switched off, or Bugsink for SQLite. Both fit run comfortably here for small number of applications.
• 4 GB: Bugsink with PostgreSQL, or GlitchTip with Valkey on and separate worker service. Na for this size you fit stop tuning and just run am.
• 8 GB: e still no reach the official Sentry stack requirement. Use the extra capacity for longer retention window and bigger disk for whichever light option you choose.
• 16 GB minimum, 32 GB recommended: official Sentry self-hosted stack, and only when you need Sentry feature wey the lighter projects no implement. Check the specific feature against each project documentation first, because the compatible projects cover the common ones.

Anything wey you run, the error tracker no fit report say e don die. Put check for am from another machine: Uptime Kuma wey dey watch from another box go tell you say the tracker dey down. Na exactly that time your application fit start dey throw errors wey nobody dey record.

When hosted plan na cheaper answer

Self-hosting error tracker make sense when data residency rules require am, or when your event volume high enough say per event pricing dey hurt. Outside those cases, do the calculation honestly. Sentry documented minimum na a 16 GB server with 4 cores and fast disk, and VPS wey get that size no be cheap VPS. Then add the operational work: crossing every hard stop one after another, and taking a snapshot before each migration, a few times every year.

GlitchTip and Bugsink change that calculation completely, because 512 MB to 4 GB na an inexpensive box and the upgrade na a docker compose pull. Na why most people wey ask this question later use one of the compatible projects instead of the official stack. Wetin dem want na error tracking, no be distributed data pipeline wey dem go dey babysit.

If you still dey work out wetin suppose dey on the server at all, the wider list of wetin worth self-hosting puts error tracking beside the other services wey dey compete for the same RAM.

FAQ

I fit self-host Sentry for a 2 GB VPS?

No. Sentry self-hosted documentation talk say you need minimum 4 CPU cores, 16 GB of RAM plus 16 GB of swap, and 20 GB of free disk. The stack dey run Postgres, ClickHouse, Kafka, Redis and several worker processes at the same time, so for small server the kernel go kill containers before the installation finish. Confirm am with dmesg -T | grep -i 'out of memory', wey dey print one line wey name the process wey e kill. For 2 GB VPS, use GlitchTip, wey document 512 MB, or Bugsink, wey dey run as one container for SQLite.

I need change my application code to move from Sentry go GlitchTip or Bugsink?

No. Both dey accept events from Sentry open source SDKs, so keep the SDK wey you don already install and change one value: the DSN, wey be the URL wey SDK dey use post events. Move am go environment variable if e still dey hardcoded, point am to the new host, then raise test exception and monitor am as e arrive. If nothing show, check say the project identifier for DSN match project wey dey exist for the new server, and say your firewall allow the application reach that host and port.

How much disk self-hosted error tracking need?

E depend on your event volume and retention window, no be mainly on the tool. GlitchTip publish 30 GB for instance wey dey handle one million events per month. Bugsink let you set the budget directly with MAX_RETENTION_EVENT_COUNT and MAX_EVENT_AGE_DAYS, so na you choose the ceiling and the disk requirement follow from am. Configure retention on the first day. Tracker wey no get retention policy go grow until df -h read 100%, and once e reach there ingest go stop and you go lose the errors wey you most need see.

Why self-hosted Sentry upgrade dey keep fail?

Because the upgrade skip one hard stop. Sentry self-hosted define specific versions wey carry database migrations wey you must pass through, and as of August 2026 dem be 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 and 26.7.0. If you move straight from old release go the newest one, you skip those migrations, so schema and code no agree and the upgrade stop halfway. Check out each hard stop in order and run ./install.sh for every one, create server snapshot before you start, and read the documented list of releases to avoid, wey include 23.7.0, 25.9.0 and 25.12.0.