For years we ran Sentry self-hosted at Skcript. It worked, but every time I looked at what it took to keep it running, I had the same thought. The job is simple: store stack traces, group them, ping me when something breaks. The setup to do that job was more than ten containers and a server sized for 16 GB of RAM plus 16 GB of swap. So we built something smaller. It's called OpenFault, and today is its first public release.

The problem with self-hosting Sentry

Sentry is a good product, and its SDKs are some of the best in the industry. They cover almost every language and framework, and most teams already have one wired into their app.

The trouble is the self-hosted version. It needs 10+ containers and a minimum of 16 GB of RAM with 16 GB of swap. That makes sense for a company tracking errors across hundreds of services. It doesn't make sense for a small team running a few apps on one VPS. You end up paying for a server bigger than the apps it's watching, and spending time looking after the error tracker instead of fixing errors.

I wanted the Sentry SDK ecosystem without the weight.

What OpenFault is

OpenFault is error tracking that's fast, beautiful, and reliable. It's a self-hosted, Sentry-compatible error tracker. One container, SQLite, MCP-first.

It's a drop-in for Sentry. The official Sentry SDKs work unchanged, and OpenFault accepts events on the same envelope ingest endpoint. The only thing you change is the DSN. Source maps upload with sentry-cli, the same way you do today. If an SDK sends something OpenFault doesn't support, like transactions, it's dropped quietly instead of rejected, so nothing in your app breaks.

Everything lives in one container with SQLite and a single /data volume. We run it in production at Skcript on a $5 Hetzner server with 2 vCPUs, 3.8 GB of RAM and a 38 GB disk. These numbers are measured on that box today, not targets.

The whole thing uses about 117 MB of RAM and a fifth of a percent of one CPU, on a $5 Hetzner box with 3.8 GB. Sentry self-hosted wants 16 GB of RAM and 16 GB of swap just to start, and recommends 32 GB. The OpenFault image is 30.5 MB. After a day in production, the data volume is 5.3 MB. The server's load average sits at 0.00.

Interactive

How many $5 servers?

One box = one $5 Hetzner server with 3.8 GB of RAM.

OpenFault · fits in 1 box, with 97% to spare

Sentry self-hosted · needs 5 of these boxes

16 GB minimum = 5 × $5 boxes

A few other things it does:

  • Groups errors by the shape of the stack (module, file and function), not by line numbers, so a small edit doesn't split one issue into five. You can also set custom fingerprints.
  • Shows a live dashboard over SSE, with a fullscreen TV mode at /tv for the screen on the office wall.
  • Sends alerts for new issues, regressions and spikes to email, Slack, Discord, Teams or a webhook.
  • Supports teams with owner, admin and member roles. Signup is closed by default.
  • Backs up daily to S3 or Cloudflare R2.
  • Keeps events for 90 days by default, set per project.

Busy issues are sampled. The first 25 events per issue per hour are kept, then 1 in 20. The counters always count every event, so the numbers stay honest.

Interactive

What gets stored

First 25 events per issue per hour, then 1 in 20.

Counted500

Stored49

StoredDropped

The counter never lies. Every event is counted, even the ones we don't keep.

It's open source under the MIT licence. There is no hosted plan and no pricing. You run it on your own server.

What it deliberately doesn't do

OpenFault does not do tracing, session replay or profiling. That's a choice, not a gap on a roadmap. Each of those is a product of its own, and each one adds storage, memory and moving parts. Leaving them out is how it stays one container.

It also doesn't import your existing Sentry history. When you switch the DSN, new errors start landing in OpenFault. Old ones stay where they were.

Built for agents first

More and more, the first one to look at an error isn't a person. It's an AI agent in someone's editor. So the error tracker should speak to agents directly, not through a scraped web page.

OpenFault has an MCP server built in. It gives an agent six tools: list_new_issues, search_issues, get_issue, resolve_issue, mute_issue and link_fix. It works with Claude Code, Cursor and VS Code.

In practice, you can ask your agent what broke overnight, have it pull the stack trace and the context, and let it propose a fix in your codebase. A fix still needs a person's approval. The agent does the digging, and a human decides what ships.

How to try it

You need Docker. Run this:

docker run -d --name openfault -p 8080:8080 -v openfault-data:/data ghcr.io/openfault/openfault:latest

Then open http://localhost:8080. A setup wizard creates your admin account and your first project. Copy the DSN it gives you, paste it into your Sentry SDK config, and errors start showing up.

The install docs cover running it on a server, and there's a page comparing it with Sentry if you want the details side by side.

What's rough

This is the first public release. We run it in production at Skcript, and it's young, so you'll find rough edges.

If something breaks, or an SDK sends something OpenFault doesn't handle well, please file an issue on GitHub. Real reports from real apps are the fastest way for it to get better.

Where this goes

The next piece is an iOS app, coming soon through TestFlight. It brings push alerts, home screen widgets and pairing with your server by scanning a QR code.

Beyond that, the plan is to keep it small. One container, the Sentry SDKs you already use, and an error tracker your agents can work with. If that sounds like what your team needs, try it at openfault.dev, and tell us what you find.