The market for self-hosted developer tooling keeps expanding, but one category remains especially hard to simplify: error tracking. Teams want the visibility of services like Sentry, but many of them do not want to run a sprawling observability stack just to capture application exceptions. That is where gosnag is trying to position itself: as a self-hosted error tracking service compatible with Sentry SDKs, designed as a lighter drop-in alternative for teams that want control over their data and infrastructure without rebuilding their client-side instrumentation.
According to its public GitHub repository, gosnag can receive events from official Sentry clients and present them in its own dashboard for monitoring, triage, and issue resolution. The project describes itself as a single binary with a Go backend, an embedded React frontend, and embedded SQL migrations, which immediately tells you what problem it is trying to solve: reduce deployment complexity while preserving compatibility with tooling developers already use.
That compatibility angle is gosnag’s biggest selling point. The README explicitly says it works with official Sentry SDKs for JavaScript, Python, Go, Ruby, Java, and more, and it shows example DSN configuration for both JavaScript and Python. In practical terms, that means a team already sending errors through Sentry-compatible SDKs may be able to switch the DSN endpoint to gosnag without rewriting application-side error reporting logic from scratch.
The project’s feature list is fairly focused. gosnag claims a real-time dashboard, issue assignment and resolution workflows, snoozing with cooldown timers, regression tracking, email and Slack alerts, configurable event retention, ingest rate limiting by IP, and role-based access control with admin and member roles. It also uses Google Identity Services for authentication and promotes the first user to admin automatically. That puts it in a very specific product category: not a full observability suite, but a dedicated self-hosted error tracking layer with enough workflow features to be useful for small and mid-sized teams.
Deployment also looks intentionally straightforward. The repository recommends Docker Compose as the default setup path, with the main required configuration variables being DATABASE_URL for PostgreSQL and GOOGLE_CLIENT_ID for authentication. For teams that prefer building from source, the prerequisites listed are Go 1.25+, Node 20+, and PostgreSQL. That is a much smaller operational footprint than many full-featured monitoring stacks, and clearly part of gosnag’s pitch.
This is also where the comparison with self-hosted Sentry becomes useful. Sentry’s own self-hosted project describes itself as feature-complete and packaged for low-volume deployments and proofs of concept, and its official documentation explains that the self-hosted distribution uses Docker Compose to orchestrate the required services. That framing matters because it highlights the difference in ambition. gosnag is not presenting itself as a complete reimplementation of everything in the Sentry ecosystem. It is aiming at a narrower problem: Sentry-compatible error ingestion and issue handling in a simpler self-hosted package.
That narrower focus is probably where gosnag has the best chance to be useful. It could make sense for small SaaS teams, internal tools, or companies with data residency or compliance concerns that still want a familiar DSN-based error tracking workflow. It could also appeal to teams that find self-hosted Sentry more than they actually need. The project does not publicly claim to cover the entire breadth of Sentry’s performance monitoring or broader observability capabilities, so the most reasonable way to evaluate it is as a focused error tracking service rather than as a universal replacement for a mature platform.
There are, however, early-stage signals to keep in mind. The public repository currently shows a very small number of commits, no published releases, and only a few stars and forks. That does not invalidate the idea, but it does suggest gosnag should be treated as an early project rather than a battle-tested standard. For anyone considering it in production, that means the usual caution applies: test carefully, validate the SDK compatibility you depend on, and make sure the narrower scope really matches your needs before committing to it.
Frequently Asked Questions
What is gosnag, exactly?
gosnag is a self-hosted Sentry-compatible error tracking service. Its repository says it can receive errors from Sentry SDK clients and provide a dashboard to monitor, triage, and resolve issues.
Does gosnag require changes to application code if a team already uses Sentry SDKs?
Potentially very few. The project documentation says it works with official Sentry SDKs and shows DSN examples for JavaScript and Python, so the main change may be pointing those SDKs to a gosnag-hosted DSN instead of another endpoint.
What does gosnag need to run?
The README lists PostgreSQL and a Google OAuth client ID as required configuration, with optional settings for SMTP, Slack alerts, retention, and rate limiting. Building from source requires Go 1.25+ and Node 20+.
How is gosnag different from self-hosted Sentry?
Based on the public documentation, gosnag is a smaller, more focused product centered on Sentry-compatible error tracking, while Sentry’s own self-hosted distribution is described as feature-complete and packaged for low-volume deployments and proofs of concept.
Does gosnag support alerts?
Yes. The repository says it supports email alerts via SMTP and Slack webhook notifications for new issues.
Is gosnag production-ready?
The public repository does not present published releases yet, and its visible GitHub activity is still limited, so the safest interpretation is that it is an early-stage project that should be evaluated carefully before production use.
What license does gosnag use?
gosnag is published under the MIT license.