sentry vs. getsentry
You'll find numerous references to both
getsentry in our documentation. Both are Django apps, but
sentry is open and
getsentry is closed. What's in which?
The main thing to emphasize is that all of our product features—Issues, Performance, Dashboards, and such—are implemented and available in
sentry, the open component. It's really important to us that we're not an "open core" company that hides key functionality behind a paywall. Sentry is as open-source as we can make it.
So what's in
getsentry, then? It implements billing and account management features for our SaaS, sentry.io.
getsentry is the Django app we deploy to production. It imports the
sentry Django app, adds some routes and models, and re-exports it.
sentry has many hooks, implemented using Django signals, which
getsentry subscribes to. For example, there's a Django signal called
sentry that is triggered when an event is saved. If you're running self-hosted, nothing is subscribed to this hook. But in
getsentry, we have a counter for billing that runs when that signal fires.
There are also some swappable backends in
getsentry utilizes, such as
sentry.quotas, and a home-grown feature flagging system. As with hooks, these modular backends are technically available to self-hosted instances, but they're largely undocumented. For example, the feature-flagging system has a hardcoded table of features (
SENTRY_FEATURES) that self-hosted installs can use to control feature availability.
getsentry registers a different feature flag handler that flips flags based on our billing plans and early access program.
Notes for Sentry Engineers
If you're not on staff at Sentry, you won't have access to develop on the
getsentry codebase and you can ignore the following notes and other mentions throughout this documentation.
You can often swap the
sentryCLI for the
getsentryCLI and they'll behave the same. In other cases, we have attempted to call out differences in behavior.
getsentry's settings are configured in
getsentry/conf/settings/defaults.py. Additional environment specific overrides are found in files matching the environment name. For example, default settings for local development are found in
getsentry/conf/settings/dev.py. You can also use
getsentry/conf/settings/devlocal.pyfor personal configuration overrides. The
devlocal.pyfile is ignored by git and won't accidentally show up in your commits.