A Sentry alternative that keeps your SDK and stores errors on your own server

The short answer#

• Keep your Sentry SDK: change the DSN and events go to Belvador.

• Events are stored on a node in your own Hetzner project, which Belvador creates, updates and backs up.

• Errors, cron and uptime monitoring, SLOs, and OpenTelemetry traces and logs live in one workspace.

• Free during the beta; Hetzner bills the server, €5.99 a month for a CX23 before VAT.

• No session replay, profiling or AI debugging. If you depend on those, stay on Sentry. Your own coding agent can read Belvador through its MCP server.

What stays the same#

• The SDK. Official Sentry SDKs for the browser, Node.js, Python and other runtimes send to a Belvador DSN. Belvador's own @belvador/* packages for React, TanStack Start and Cloudflare Workers wrap the same Sentry engine (10.76.2) and add privacy defaults (SDK overview).

• Source maps. Upload with sentry-cli as you do today (source maps).

• Cron check-ins. Sentry.withMonitor() and captureCheckIn() work against Belvador monitors (monitors with Sentry SDKs).

• Issues. Events are grouped into issues with a stable fingerprint, and you resolve, ignore and assign them as you would expect.

What changes#

• Where events live. On a node in your own Hetzner project, which Belvador creates, updates and backs up. Belvador's control plane keeps settings and counts, not event bodies (BYOC on Hetzner).

• What you pay. Free during the beta; Hetzner bills the server, a CX23 lists at €5.99 a month before VAT (pricing).

• Alert senders. Alerts go out through your own Telegram bot, Slack webhook, email account or signed webhook (alerts).

Compared one by one#

Each page cites the competitor's public pages with the date we read them.

Switching in one afternoon#

1. Create a workspace and connect a dedicated Hetzner project. The node was ready in about 90 seconds in our tests (connect Hetzner).

2. Create a project and copy its DSN.

3. Swap the DSN in your app; for React, TanStack Start or Workers, swap the import too (migrate from Sentry).

4. Prove the connection from production with one tagged test error (verify).

5. Point sentry-cli at Belvador for source maps.

6. Move cron monitors and uptime checks when you are ready (cron monitoring, uptime monitoring).

What Belvador does not do#

• Session replay, profiling, user feedback widgets. Not available.

• AI debugging. Not available — your own agent reads issues, traces and logs through the MCP server instead.

• No on-call schedules, status pages, phone or SMS alerts. Alerts go to Telegram, Slack, email or a webhook you own.

• Other clouds. The node runs on Hetzner Cloud only, one node per workspace.

• Next.js. No tested Belvador package yet; the official Sentry SDK with a Belvador DSN is untested here.

What you leave behind#

Belvador starts with an empty history: issues and events already in Sentry are not imported. Keep Sentry read-only for a few weeks if you need to look things up. Dashboards, saved searches and alert rules are set up again in Belvador.

Questions#

Do I have to rewrite error handling?#

No. If you call Sentry's API directly, only the DSN changes. Belvador's packages export the same function names (captureException, withScope, setTag …).

Can I run Belvador and Sentry side by side?#

Yes, from separate SDK clients. You can send one environment to Belvador first, compare the issues for a week, then move the rest.

Is Belvador open source?#

The SDK packages are MIT on npm. The service itself is not open source; the part you host is the node, which Belvador runs for you in your Hetzner project.