sentry vs. getsentry

You'll find numerous references to both sentry and 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.

Additionally, sentry has many hooks, implemented using Django signals, which getsentry subscribes to. For example, there's a Django signal called event_received in 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 sentry that getsentry utilizes, such as sentry.nodestore, 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.

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 sentry CLI for the getsentry CLI 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.py for personal configuration overrides. The devlocal.py file is ignored by git and won't accidentally show up in your commits.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").