---
title: "sentry vs. getsentry"
url: https://develop.sentry.dev/application-architecture/sentry-vs-getsentry/
---

# sentry vs. getsentry

You'll find numerous references to both `sentry` and `getsentry` in our documentation. Both are [Django](https://www.djangoproject.com/) apps, but `sentry` [is open](https://github.com/getsentry/sentry) and `getsentry` is closed. What's in which?

The main thing to emphasize is that all of our product features—[Issues](https://docs.sentry.io/product/issues/), [Insights](https://docs.sentry.io/product/insights/), [Dashboards](https://docs.sentry.io/product/dashboards/), and [such](https://docs.sentry.io/product/)—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](https://open.sentry.io/licensing/).

So what's in `getsentry`, then? It implements billing and account management features for [our SaaS, sentry.io](https://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](https://develop.sentry.dev/self-hosted.md), 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`](https://github.com/getsentry/sentry/blob/master/src/sentry/features/__init__.py)) that [self-hosted installs can use](https://develop.sentry.dev/backend/feature-flags.md) to control feature availability. `getsentry` registers a different feature flag handler that flips flags based on our [billing plans](https://sentry.io/pricing/) and early access program.

## [Notes for Sentry Engineers](https://develop.sentry.dev/application-architecture/sentry-vs-getsentry.md#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 `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`](https://github.com/getsentry/getsentry/blob/master/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`](https://github.com/getsentry/getsentry/blob/master/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.