Self-hosted error monitoring on a $5 VPS in 2026.

Why this question matters again in 2026

The “self-host vs. hosted” debate for error monitoring has been a recurring one since Sentry’s pricing changed in 2022, and it has been particularly loud through 2024–2026 as plan tiers tightened further. The standard advice — “use hosted Sentry, it’s worth it” — quietly assumed two things that no longer hold for a lot of teams:

• That the cost line for hosted Sentry would stay tolerable as projects, environments, and replay/profiling SKUs got added.
• That self-hosted Sentry was a realistic fallback if the hosted bill ever became unreasonable.

The first assumption broke quietly. The second broke loudly: the getsentry/self-hosted README now states a 16 GB RAM minimum, and the issue tracker has years of reports from operators who needed substantially more to keep the stack stable. The interesting question is no longer “should you self-host Sentry?” It’s “if you do want to self-host an error tracker, what actually fits on the kind of hardware most teams have lying around?”

That kind of hardware is, very often, a $5 VPS.

What “$5 VPS” actually buys you in 2026

The price point has held remarkably steady. The shape of what it buys has changed:

The interesting outlier is Hetzner — the CPX11 is closer in spec to what would have been a “small production box” three years ago. Anywhere outside the EU, the $5–6 tier is closer to the DigitalOcean / Vultr / Linode shape: 1 GB of RAM, one vCPU, and 25 GB of SSD. That is the floor this guide is written against, because anything above it is more headroom than the post requires.

One thing to verify before you commit to a provider: that the cheapest tier is not running on a shared, throttled disk. SQLite tolerates a real SSD very well and a contended one very poorly. If fio on the box reports four-digit IOPS, you are fine. If it reports two-digit IOPS, pick a different provider.

Why Sentry self-host is not on this list

It is worth being precise about why Sentry’s own self-hosted distribution is not a credible option on this hardware, because the question comes up constantly.

The Sentry self-host stack is not one process. It is, by the current Compose file, roughly twenty containers — Postgres, Redis, Kafka, ZooKeeper, ClickHouse, Snuba (multiple), Symbolicator, Vroom, Relay, web, worker, cron, ingest-consumer, post-process-forwarder, plus supporting services. Each one has a memory floor. The aggregate floor is what produces the 16 GB recommendation in the project README.

The 16 GB number is also a paper minimum. The issue tracker has multiple long-running threads of operators reporting the gap between the documented minimum and the practical one:

• getsentry/self-hosted#3566 — memory exhaustion under non-trivial ingest on documented-minimum hardware.
• getsentry/self-hosted#3467 — OOM behavior with default container limits.
• getsentry/self-hosted#1719 — Kafka and ZooKeeper baselines on a fresh install.
• getsentry/self-hosted#1521 — recurring "minimum hardware" thread.
• getsentry/self-hosted#2262 — disk usage growth from ClickHouse and Kafka over time.

The community-side commentary tracks the same shape. The Bugsink author’s Hacker News thread got attention precisely because the framing — "Sentry is too much for what most teams need" — is something a lot of operators agree with after their first try.

“I ran Sentry self-host on a 32 GB box and ClickHouse alone took 12. There is no version of this that runs on a small VPS.”

That is the consensus, and it is the consensus from people who tried hard to make it work.

The single-binary tracker landscape

What has happened since 2022 is that several projects deliberately picked a different shape: one process, embedded database, optional Postgres. The current contenders that will run on a 1 GB host are:

urgentry

A Go single-binary Sentry-compatible tracker. SQLite by default; Postgres optional for larger deployments. On the reference Tiny lane it sustains roughly 400 events per second with a peak resident memory footprint near 52 MB. Source-scanned OpenAPI coverage matches 218 of 218 Sentry operations, which makes drop-in SDK migration the common path. Where it is behind Sentry today: session replay is partial rather than full, and some product surfaces (native crash, advanced ownership rules) have narrower coverage than the hosted product. Disclosure: this guide is published on urgentry.com, so treat the gap claims as ones to verify against the compatibility matrix.

Bugsink

A Django + SQLite tracker, Sentry-SDK-compatible, with a deliberate "small and stays small" design ethos. The project author has been explicit on Hacker News that Bugsink is opinionated about staying inside one process. If you are a Django shop with a moderate event volume and you want the smallest opinionated path, Bugsink is the natural pick. Documentation is at bugsink.com.

GlitchTip

The longest-running open-source Sentry-compatible project of this generation. Django + Postgres is the supported deployment; SQLite is possible for tiny installs. The community is established, the Helm chart works, and the product surface is well-understood. Where GlitchTip lags: depth of newer Sentry features (replay, profiling) is narrower than urgentry’s. Project site: glitchtip.com.

Errsole

A Node.js-centric option focused more on log capture than the full error-monitoring surface. If your stack is Node and what you actually want is structured logs plus light error grouping, Errsole is worth a look. It is not a drop-in Sentry SDK target.

SQLite or Postgres on a tiny host

The question that comes up next is whether SQLite is “real” enough for production error monitoring. This is the wrong frame. The right frame is: does the workload have one writer or many? An error tracker on one host has one writer — the tracker process. That is exactly the shape SQLite is best at.

A few specifics worth knowing:

• SQLite in WAL mode comfortably sustains low-thousands of writes per second on a real SSD. The Tiny lane benchmark sits at 400 events per second with peak resident memory at ~52 MB and the WAL behaving normally.
• The hard limit for SQLite on a small host is not write throughput. It is concurrent expensive reads. If two humans run a slow Discover query at the same time, they will serialize.
• Postgres becomes the right answer when you have multiple application instances ingesting against a shared database — i.e. when you have moved off the one-host shape entirely. There is no in-between on a tiny host where Postgres helps but the cost of running Postgres on the same 1 GB box is justified.

For the $5 VPS shape specifically: SQLite, in WAL mode, with continuous backup. Anything more elaborate is a smell.

A concrete setup, end to end

The walkthrough below uses urgentry as the example because that is the tracker this site documents, but the same shape applies to Bugsink and to GlitchTip-on-SQLite. The five decisions are identical:

1. Pick a host with a real disk.
2. Pick a tracker that runs as one process against an embedded database.
3. Put it behind a TLS reverse proxy.
4. Configure continuous backup.
5. Point one SDK at the new DSN and confirm one event.

Install and first boot

urgentry ships as a single binary. The install script downloads the release archive, verifies the signature, and places the binary in /usr/local/bin. There is no Docker daemon to install, no Compose file to maintain, and no database to provision.

curl -fsSL https://urgentry.com/install.sh | sh
URGENTRY_BASE_URL=https://errors.example.com ./urgentry serve --role=all

On first boot, urgentry writes a bootstrap owner credential and a default project ingest key into the data directory. Bugsink and GlitchTip both have equivalent first-boot flows. The detail that matters across all three: write down the bootstrap credentials. Recovering them later is more painful than copying them now.

TLS in one Caddyfile line

The tracker should never be exposed on a public port. Caddy is the smallest path to TLS on a small host: one config line, automatic certificate provisioning from Let’s Encrypt, and reverse proxy to the local port.

errors.example.com {
  reverse_proxy localhost:8080
}

nginx and Traefik are reasonable substitutes if either is already in your toolbox. Caddy is the default recommendation because the config surface is roughly two orders of magnitude smaller.

Continuous backup

This is the step the largest share of $5 setups skip, and the one that causes most data loss when it goes wrong. The SQLite file is the system of record for every event, group, release, and source map you have ingested. If the host disk fails and you do not have a continuous backup, you have lost everything.

The right tool is Litestream. It streams SQLite WAL frames to an S3-compatible bucket continuously, with no impact on writer performance. R2, Backblaze B2, and DigitalOcean Spaces are all viable destinations at $5/month or less of additional cost.

litestream replicate /var/lib/urgentry/urgentry.db \
  s3://urgentry-backups/$(hostname)/urgentry.db

The same Litestream command works for Bugsink and for GlitchTip-on-SQLite. Test the restore path before you need it.

Hardening checklist

The minimum responsible configuration for a public-facing tracker is:

• TLS terminated at the reverse proxy with HTTP-to-HTTPS redirect.
• UFW or nftables restricting inbound traffic to ports 80 and 443.
• fail2ban configured against the SSH and reverse-proxy access logs.
• SSH key-only authentication; password authentication disabled.
• Unattended-upgrades enabled for security patches.
• A non-root user for the tracker process, with a dedicated systemd unit.

None of this is specific to error monitoring. It is the same baseline any internet-facing service needs, and skipping it is the failure mode that turns a small box into a footnote in an incident report.

What breaks first on a $5 box

Most $5 setups that fail do so in a predictable order. In rough order of likelihood:

• Disk fill from source maps and attachments. A handful of large JS bundles or a few minidumps will eat through 25 GB faster than you expect. Configure a retention policy early.
• Backups you set up once and never tested. Litestream restores are easy when the workflow is rehearsed and uncomfortable when it is not.
• Concurrent heavy queries under load. Two humans on Discover at the same time will serialize. This is a shape problem, not a bug.
• Ingest spikes from a runaway client. A frontend deploy that throws on every page load will fill the ingest queue. Server-side sampling at the DSN level is the only durable fix.
• RAM growth from a single rogue group. A high-cardinality fingerprint can blow up tag indexes. Group merging is the recovery; capping fingerprint cardinality is the prevention.

The thing that almost never breaks first on a $5 box is the ingest path itself. The trackers in this category are designed around the assumption that ingest is hot and queries are warm. If something is going to fail, it is the query side or the disk.

When to graduate from a $5 box

The $5 shape works for personal projects, side projects, small teams, internal tools, and pre-revenue SaaS. The signals that you have outgrown it are concrete:

• Sustained ingest above ~400 events per second across the day, not just at peak.
• More than two or three humans regularly querying issues at the same time.
• Native crash workloads with minidump processing — symbolication is CPU- and memory-heavy and does not fit alongside SQLite on 1 GB.
• Compliance requirements (SOC 2, ISO 27001) that mandate redundancy, HA, or audit trails the single-host shape cannot easily provide.
• Multiple application instances behind a load balancer that need to share an event database for cross-instance grouping.

When any of those is true, the right move is to switch to a Postgres backend on a bigger host (urgentry, GlitchTip), shard out workers (urgentry’s Serious mode, Sentry’s self-host), or buy a managed plan. Staying on a $5 box past the point it fits is the failure mode that produces the worst incidents.

When you should not self-host at all

This guide is biased toward self-hosting because that is the question it is answering. The honest counter is that self-hosting is the wrong choice when:

• Your team has zero ops capacity and a meaningful budget. Pay Sentry.
• You need full session replay on day one as a non-negotiable product feature.
• You operate in a compliance regime where the vendor-managed control plane is itself a requirement (some HIPAA / FedRAMP shapes).
• You are early-stage and the founder hours saved are worth more than the bill.

Self-hosting is a real choice with real ongoing costs. The $5 box is cheap; your time is not. Make sure the tradeoff actually favors you before you commit.

Frequently asked questions