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 thegetsentry
CLI and they'll behave the same. In other cases, we have attempted to call out differences in behavior.getsentry
's settings are configured ingetsentry/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 ingetsentry/conf/settings/dev.py
. You can also usegetsentry/conf/settings/devlocal.py
for personal configuration overrides. Thedevlocal.py
file is ignored by git and won't accidentally show up in your commits.
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").