Sentry's self-hosted server is 0.0.0 in both manifests, on purpose

Version 0.0.0 in package.json and 0.0.0 in pyproject, and neither is a release

Two manifests, one version, and an explanation in each. package.json declares name sentry, version 0.0.0 and private true, with type set to module. pyproject.toml declares the same name and the same 0.0.0, with a comment that setup.cfg holds the real version and that the file is there to make uv happy, used for dependency management and not packaging. The consequence is that there is nothing to install. Sentry is not a pip package and not an npm package; the releases named 26.9.0 on 2026-09-15, 26.8.0 on 2026-08-15 and 26.7.2 on 2026-07-28 are built server artifacts, and the .craft.yml file at the root is part of that release tooling. A self-hoster follows the self-hosted/ directory and the documentation site, and a developer clones the tree and starts the environment by hand.

make develop does not build anything, it calls devenv sync

The Makefile's default target is develop, and develop does nothing itself. It delegates to another target, devenv-sync, which runs a single command, and install-js-dev and install-py-dev resolve to that same target, with a comment explaining that the indirection exists so devenv sync is called only once when the macros are combined on one make invocation. A separate bootstrap target does not execute either: it prints a note that devenv bootstrap is typically run on new machines and suggests devenv sync to bring the environment up to date. So the environment definition lives in the devenv/ directory rather than in the Makefile or in a requirements file. Reproducing a colleague's setup means having that tool available, and the Makefile gives you no fallback path for a machine that does not.

Eight database targets all funnel into ./scripts/do.sh, drop-db among them

The database lifecycle is one shell script. build-platform-assets, clean, init-config, run-dependent-services, drop-db, create-db, apply-migrations and reset-db are declared as a single multi-target rule, and each one executes ./scripts/do.sh with the target name as its argument. Two things follow. First, the destructive targets sit in the same list as the constructive ones, so a mistyped make target name and a mistyped subcommand are the same operation: the shell script is the only thing that knows which names destroy a database and which build a platform asset. Second, migrations are not a loose convention here. The tree carries migrations_lockfile.txt, and the Python dependencies include django-pg-zero-downtime-migrations, which is a specific choice about how schema changes reach a live PostgreSQL. Read scripts/do.sh before you type reset-db in a directory that has a connection string in it.

requires-python is >=3.13 because backports-zstd has no cp314 wheel

The Python floor is set by packaging, not by the code. pyproject.toml requires Python 3.13 or newer, and the comment above the line explains why: without it, uv derives requires-python from whichever interpreter runs it, so a uv lock executed under Python 3.14, by dependabot for example, resolves for 3.14 and then fails on wheel-only packages such as backports-zstd, which have no cp314 wheels. Read that as a standing constraint. An automated dependency bump that changes the interpreter can break the lock file for everyone, and the fix is not to raise the floor but to keep it pinned where the wheels exist. The same file also carries the reason this dependency set is as wide as it is: asyncpg for PostgreSQL, confluent-kafka, datadog, fido2 for passkeys, google-cloud-spanner, google-cloud-bigtable, and a long list of google-cloud libraries for the serverless and storage paths.

The lint chain is oxfmt, oxlint and stylelint, and the fix command skips the CSS one

Linting is three tools in a fixed order. The lint script runs the format check, then the JavaScript check, then the CSS check, and the underlying commands are:

oxfmt --check
oxlint
stylelint '**/*.[jt]sx'

The fix script runs the formatter and the JavaScript fixer, in that order, and nothing else. There is no stylelint equivalent in it. So a contributor who runs the fix command after a lint failure gets formatting and JavaScript problems resolved and CSS problems left exactly as they were, with the check script as the only thing that will report them. That asymmetry is small, but it is the kind of detail that shows up as a second failed CI run. The rest of the toolchain follows the same pattern of one script per job, from test-ci with a capped worker count to typecheck, which builds two tsconfig projects at once, the main one and the service worker one.

test-precommit passes -u, so the pre-commit run can rewrite your snapshots

The test scripts are four separate entry points, and one of them behaves differently from what its name suggests. test runs with --watch, test-ci runs with --ci, a worker cap of 75% and colours, test-debug opens an inspector breakpoint, and test-staged runs only the tests related to files staged in git. The odd one is test-precommit, which runs with --bail and --findRelatedTests and then passes -u, the flag that updates snapshots rather than comparing them. A pre-commit hook that runs this can therefore change assertions in your working tree and still exit successfully. The repository has jest.config.snapshots.ts at the root, so there are snapshots to rewrite. The consequence for review is that a diff containing unexpected snapshot churn may have been produced by your own hook, so check the working tree after a failed pre-commit rather than assuming a colleague changed it.

Two spec generators have to agree with a schema repository, checked by diff

The public API surface is generated twice and then reconciled. build-api-docs depends on build-deprecated-docs, which runs through pnpm, and on build-spectacular-docs, which produces a schema straight from the Django code:

OPENAPIGENERATE=1 sentry django spectacular --file tests/apidocs/openapi-spectacular.json --format openapi-json --validate --fail-on-warn

A third target dereferences the JSON schema for ease of use, and diff-api-docs compares the local API docs against a file held in a separate sentry-api-schema repository. That is a real constraint on contributions. Changing an endpoint touches generated artefacts, and the failure you get is a diff against an external schema, not a reviewer's opinion, which is a good property but a confusing first experience. The Makefile also carries a full translation pipeline, merge-locale-catalogs, compile-locale, install-transifex and push-transifex, each of which installs Babel or the transifex client on demand, matching the Transifex link in the resource list.

Twenty-one SDKs, and the Perl one is still called perl-raven

The SDK list is the most concrete thing the short README offers, and it is worth reading for the naming rather than the coverage. Most repositories follow sentry- plus the platform: sentry-javascript, sentry-python, sentry-go, sentry-rust, sentry-java, sentry-cocoa for Objective-C and Swift, sentry-dotnet for C# and F#, sentry-unity, sentry-unreal, sentry-godot. Three break the pattern. C and C++ live in sentry-native, Clojure lives in sentry-clj, and Perl lives in perl-raven, a leftover from the client's earlier name that is the only entry not following the convention. The practical effect is that a developer looking for the Perl integration by guessing sentry-perl finds nothing, and a search across the organisation for sentry- prefixed repositories misses it entirely. Two of the listed SDKs are also for host environments rather than languages, Electron and React Native, and PowerShell and Dart and Flutter sit alongside the mainstream ones.

Editorial conclusion

Budget a day before you try to build the Sentry server, because reproducing a developer's environment means devenv sync rather than pip install, and the database is created and migrated through scripts/do.sh targets. If you only want error reporting, the SDKs are separate repositories and that is the part you install. Read the LICENSE.md file yourself: GitHub reports this repository's licence as NOASSERTION.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes