sentry-go is the official Go client, and it wants to replace raven-go

A client library, not a service to deploy

sentry-go is a Go module that reports errors and tracks application performance to Sentry. There is no daemon to install, no collector to run and no configuration file to mount. The whole dependency is a module path, and the whole setup is a DSN. That distinction matters when you are comparing it with a self-hosted error tracker: the SDK is the client half of a system where the Sentry service itself is a separate, hosted product at sentry.io, and the README links the platform documentation for it. What the library does is capture panics and errors, attach context, ship the payload, and do so with a transport layer the caller can influence. The README points at two runnable examples under _examples/, one for basic error instrumentation and one for error and tracing together on an HTTP server.

DSN, release and environment come from the environment by default

Initialization takes a DSN and a set of options exposed as ClientOptions. The part worth knowing is what happens when you do not pass them. The README states that if they are not specified in the SDK initialization, the DSN, the Release and the Environment are read from the environment variables SENTRY_DSN, SENTRY_RELEASE and SENTRY_ENVIRONMENT. That default is what makes the library usable in a container: bake SENTRY_DSN into the deployment, and the same binary can be pointed at a different Sentry project per environment without a rebuild. It also means a misconfigured deployment fails quietly in the sense that the SDK simply has no DSN, and the application keeps running without reporting anything. The module is at github.com/getsentry/sentry-go and the API reference lives on pkg.go.dev, so the full option list is a documentation lookup rather than a guess.

Installing it takes one go get

The README states that sentry-go can be installed like any other Go library through go get, and that the only requirement is a Go compiler.

$ go get github.com/getsentry/sentry-go@latest

Behind that one line sits a deliberate version policy. The project follows Go's official release policy and supports the two most recent Go releases, with each major Go release supported until there are two newer major releases. The exact versions are pinned in the GitHub workflow for tests, and the maintainers also run tests against the current master branch of the Go toolchain, though they describe that configuration as best-effort. In practice that means your Go version constrains which sentry-go release you can use, and the go.mod in the repository declares go 1.25.0, which is a floor you should check against your own toolchain before the first build rather than after it.

One repository, many framework adapters

The top-level tree shows how wide the surface is. Beyond the core files, client.go, hub.go, dsn.go, exception.go, batch_processor.go, baggage.go and check_in.go, there are directories for http/, httpclient/, attribute/, cron/, grpc/, echo/, fasthttp/, fiberv3/, gin/, plus a crosstest/ directory that exercises the package across dependencies. The README lists guides for net/http, echo, fasthttp, fiber, gin, iris, logrus, negroni, slog and zerolog, which tells you the intended adoption path: pull in the core client, then add the adapter for the HTTP framework or logger you already use. The check_in.go file and the cron/ directory point at a second use case, scheduled and background work that reports health rather than failures. The presence of _examples/ and crosstest/ alongside the adapters is a decent sign that behaviour is verified against more than one stack.

The build and test targets are Go workspace aware

Development happens in a Go workspace rather than a single module. The Makefile derives the list of module directories from the workspace itself.

ALL_GO_MOD_DIRS := $(shell $(GO) work edit -json | jq -r '.Use[].DiskPath')

Every target then runs across all of them, which is how a repository with several adapter modules keeps them in step.

test: ## Run tests across all workspace modules
	$(GO) test -count=1 -timeout $(TIMEOUT)s work

The same pattern applies to build, vet, and two coverage targets, one of them with race detection, and a mod-tidy target that runs go mod tidy in every module and then fails on a non-empty git diff. That last target is a good indicator of how releases are kept clean: a stray dependency in one adapter module blocks the check. A reader who only wants to consume the SDK does not need any of this, but it explains why the adapter directories carry their own go.mod files.

raven-go still exists, and the README points at the exit

This SDK describes itself as the next generation of the Go SDK for Sentry, intended to replace the raven-go package. The README is careful not to pretend raven-go is gone: it keeps a pointer to the legacy client documentation and a separate link to the migration guide. The repository carries a MIGRATION.md at the root, and the go.mod still requires github.com/pkg/errors and github.com/pingcap/errors, packages that were standard companions of the older error-handling patterns. If you are upgrading an existing service, the honest summary is that the migration is a code change in your call sites, not just a dependency bump, and the README does not enumerate the API differences. It also does not document a deprecation timeline for raven-go, so how long you can keep both in one codebase is a question for the maintainers rather than something stated in the repository.

Version 0.x, frequent releases, MIT terms

The numbering is the first thing to notice. The recent releases are v0.50.0 on 2026-10-08, v0.49.0 on 2026-08-26 and v0.48.0 on 2026-07-14, and the last push was on 2026-10-15. The project is not archived and it is moving, but a 0.x module carries no compatibility promise under Go module conventions, so pin the version in go.mod rather than tracking the branch if you care about reproducible builds. The release cadence is roughly monthly, which makes upgrade cost a recurring line item rather than a one-time event, and each release should be read in CHANGELOG.md before you take it. The licence is MIT, with the LICENSE file in the repository root, so the SDK can be vendored, modified and shipped inside proprietary products without a separate commercial agreement. The remaining obligations are the standard ones: keep the copyright notice and the licence text with redistributed copies.

Editorial conclusion

sentry-go suits Go teams that want error reporting and performance tracing from the official client, especially those migrating off raven-go, since the repository ships MIGRATION.md and a migration guide. It is the wrong tool for a service that must not talk to sentry.io, since the DSN points at a hosted endpoint, and it is the wrong choice for a Go release older than the two most recent versions the SDK supports. Before adopting it, check three things: whether your Go toolchain is recent enough for the go 1.25.0 directive in go.mod, which framework adapter your HTTP stack actually needs, and whether raven-go is still in your dependency graph, because a mixed deployment sends the same errors through two clients.

Frequently asked questions

Official sources

1. getsentry/sentry-go on GitHub
2. License: MIT
3. Project website
4. README
5. Releases