Self-Hosted Sentry

In addition to making its source code available publicly, Sentry offers and maintains a minimal setup that works out-of-the-box for simple use cases. This version comes with no guarantees or dedicated support. Sentry engineers will do their best to answer questions and are dedicated to making sure self-hosted is running, but that's where our involvement ends. For anything else, we expect users to rely on the Sentry Self-Hosted community on Discord. The self-hosted repository should serve as a blueprint for how various Sentry services connect for a complete setup. This will be useful for folks willing to maintain larger installations with custom infrastructure.

For the sake of simplicity and ubiquity, we have chosen to use Docker and Docker Compose, along with a bash-based install and upgrade script.

If you're self-hosting Sentry and want to know how to switch to Sentry SaaS, check out this live workshop to learn more about our relocation tooling.

The difference only resides on a few things that are impossible to be hosted by most people and billing/payment-related. These are some of the things that are not available on self-hosted (due to previous reasons):

To put things simply, consider self-hosted as the Business plan without any software limitations and no paid tier.

Our recommendation is to download the latest release of the self-hosted repository, and then run ./install.sh inside this directory. This script will take care of all the things you need to get started, including a base-line configuration, and then will tell you to run docker compose up -d to start Sentry. Sentry binds to port 9000 by default. You should be able to reach the login page at http://127.0.0.1:9000.

To have easy maintainability for future upgrades, it is recommended to use Git workflow by cloning the self-hosted repository and check out to a specific CalVer tag. More about this on Releases & Upgrading.

Copied
# Assuming current latest version is 24.1.0
# Current actual version can be acquired from the Releases page on GitHub
VERSION="24.1.0"
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
sudo ./install.sh

We require at least Docker 19.03.6 and Compose 2.19.0.

These are the minimum requirements:

  • 4 CPU Cores
  • 16 GB RAM
  • 20 GB Free Disk Space

We'd recommend using a swapfile whenever applicable. Depending on your traffic volume, you may want to increase your system specification to handle increased load. If increasing the disk storage space isn't possible, you can migrate your storage to use external storage such as AWS S3 or Google Cloud Storage (GCS). Decreasing your SENTRY_RETENTION_DAYS environment variable to lower numbers will save some storage space from being full, at the cost of having shorter data retention period. See Event Retention section below.

When you run ./install.sh, you have a choice to opt in or out of our monitoring. This monitoring is used for development and debugging purposes so that we're on top of issues you're facing, allowing us to provide a more seamless installation process. If you opt into our monitoring, we will send information to our own self-hosted Sentry instance for development and debugging purposes. We may collect:

  • OS username
  • IP address
  • install log
  • runtime errors in Sentry
  • performance data

Thirty (30) day retention. No marketing. Privacy policy at sentry.io/privacy.

Starting with the 22.10.0 release, we will require those running the Sentry installer to choose to opt in or out. If you are running the installer under automation, you may want to set REPORT_SELF_HOSTED_ISSUES or pass --(no-)report-self-hosted-issues to the installer accordingly.

If you opt-in to it, self-hosted Sentry will periodically communicate with a remote beacon server. This is utilized for a couple of things, primarily:

  • Getting information about the current version of Sentry
  • Retrieving important system notices

The remote server is operated by the Sentry team (sentry.io), and the information reported follows the company's privacy policy.

The following information is reported:

  1. A unique installation ID
  2. The version of Sentry
  3. A technical contact email if opted in to sending contact info (system.admin-email)
  4. General anonymous statistics on the data pattern (such as the number of users and volume of errors)
  5. Names and version of the installed Python modules

Note: The contact email is utilized for security announcements, and will never be used outside of such. You can change your opt in/out settings for sending contact info at any time in the settings of the admin panel.

The data reported is minimal and it greatly helps the development team behind Sentry. With that said, you can disable the beacon with the following setting:

Copied
SENTRY_BEACON = False

In some enterprise setups there is no direct Internet connection, so you must use an HTTP proxy server. How do you install Sentry in this environment? Let us assume:

  1. Your Sentry installation is running on Linux.
  2. http://proxy:3128 is your proxy address.
  3. 127.0.0.0/8 is the only network that should be accessed without a proxy.

Here are the steps to follow:

  1. Set http_proxy, https_proxy and no_proxy variables in the /etc/environment file.
  2. To make the docker pull command respect your proxy settings, create a /etc/systemd/system/docker.service.d/http-proxy.conf file with these contents:
Copied
[Service]
Environment="HTTP_PROXY=http://proxy:3128"
Environment="HTTPS_PROXY=http://proxy:3128"
Environment="NO_PROXY=127.0.0.0/8"
  1. Run systemctl daemon-reload and restart Docker with systemctl restart docker.service.

From there you can run ./install.sh like usual.

By default Sentry sends anonymous usage statistics to the Sentry team. It helps to improve the product. You can disable this feature by adding SENTRY_BEACON = False into sentry.conf.py file. Also there can be different external integrations with third party services like Slack or Twilio. To make these features work it's required to allow Docker containers to access the Internet. To add your proxy environment variables into Sentry's Docker containers, create /etc/docker/config.json file (or ~/.docker/config.json if you're running Docker on rootless mode) with these contents:

Copied
{
  "proxies": {
    "httpProxy": "http://proxy:3128",
    "httpsProxy": "http://proxy:3128",
    "noProxy": "smtp,memcached,redis,postgres,kafka,clickhouse,snuba-api,symbolicator,web,worker,nginx,relay,vroom,172.17.0.0/16,127.0.0.0/8"
  }
}

To apply new Docker daemon configuration, restart your Docker service with systemctl restart docker.service.

You very likely will want to adjust the default configuration for your Sentry installation as well. These facilities are available for that purpose:

  1. sentry/config.yml—Contains most, if not all, configuration options to adjust. This file is generated from sentry/config.example.yml at the time of installation. The file itself documents the most common configuration options as code comments. Some popular settings in this file include:

    1. system.url-prefix (we prompt you to set this at the welcome screen, right after the installation)

    2. mail.* (though we do ship with a basic SMTP server)

    3. integrations for GitHub, Slack, etc.

  2. sentry/sentry.conf.py—Contains more advanced configuration. This file is generated from sentry/sentry.conf.example.py during installation.

  3. sentry/enhance-image.sh—To install plugins and their dependencies or make other modifications to the Sentry base image, copy sentry/enhance-image.example.sh to sentry/enhance-image.sh and add necessary steps there. For example, you can use apt-get to install dependencies and use pip to install plugins. After making modifications to sentry/enhance-image.sh, run ./install.sh again to apply them.

  4. Environment variables—The available keys are defined in .env. Use some system-dependent means of setting environment variables if you need to override any of them. To avoid Git changes, simply create a file called .env.custom and insert your system-dependent environment variables there. In order to use this, please use docker compose --env-file /path/to/.env.custom up -d.

  5. Geolocation uses a custom configuration file to conform to the underlying technology.

You can find more about configuring Sentry at the configuration section of our developer documentation.

Sentry comes with a cleanup cron job that prunes events older than 90 days by default. If you want to change that, you can edit the SENTRY_EVENT_RETENTION_DAYS environment variable in .env or simply override it in your environment. If you do not want the cleanup cron, you can remove the sentry-cleanup service from the docker-compose.yml file.

If you want to install a specific release of Sentry, use the tags/releases on the self-hosted repository.

We continuously push the Docker image for each commit made into Sentry, and other services such as Snuba or Symbolicator to our Docker Hub and tag the latest version on master as :nightly. This is also usually what we have on sentry.io and what the install script uses. You can use a custom Sentry image, such as a modified version that you have built on your own, or simply a specific commit hash by setting the SENTRY_IMAGE environment variable to that image name before running ./install.sh:

Copied
SENTRY_IMAGE=getsentry/sentry:83b1380 ./install.sh

Note that this may not work for all commit SHAs as this repository evolves with Sentry and its' satellite projects. It is highly recommended to check out a version of this repository that is close to the timestamp of the Sentry commit you are installing.

Only features that have reached General Availability (GA) status will be enabled by default for self-hosted. As users, you can try new features before it reaches GA by adding required infrastructure components and feature flags. Preview features are tracked and documented through GitHub issues with Type: Pre-release Feature labels.

Environment specific configurations can be done in the .env.custom file. It will be located in the root directory of the Sentry installation, and if it exists then .env will be ignored entirely.

By default, there exists no .env.custom file. In this case, you can manually add this file by copying the .env file to a new .env.custom file and adjust your settings in the .env.custom file.

Please keep in mind to check the .env file for changes, when you perform an upgrade of Sentry, so that you can adjust your .env.custom accordingly, if required, as .env is ignored entirely if .env.custom is present.

To install plugins and their dependencies or make other modifications to the Sentry base image, copy sentry/enhance-image.example.sh to sentry/enhance-image.sh and add necessary steps there. For example, you can use apt-get to install dependencies and use pip to install plugins.

After making modifications to sentry/enhance-image.sh, run ./install.sh again to apply them.

Here is further information on specific configuration topics related to self-hosting:

We strongly recommend using a dedicated load balancer in front of your Sentry setup bound to a dedicated domain or subdomain. A dedicated load balancer that does SSL/TLS termination that also forwards the client IP address as Docker Compose internal network (as this is close to impossible to get otherwise) would give you the best Sentry experience. As part of this setup we recommend configuring a load balancer health check against the /_health/ endpoint using HTTP protocol. This will return a 200 if Sentry is up or a 500 with the list of problems.

Once you have setup a load balancer or reverse proxy to your Sentry instance, you should modify the system.url-prefix in the config.yml file to match your new URL and protocol. You should also update the SSL/TLS section in the sentry/sentry.conf.py script, otherwise you may get CSRF-related errors when performing certain actions such as configuring integrations.

Keep in mind that all this setup uses single-nodes for all services, including Kafka. For larger loads, you'd need a beefy machine with lots of RAM and disk storage. To scale up even further, you are very likely to use clusters with a more complex tool, such as Kubernetes. Due to self-hosted installations' very custom nature, we do not offer any recommendations or guidance around scaling up. We do what works for us for our thousands of customers over at sentry.io and would love to have you over when you feel your local install's maintenance becomes a burden instead of a joy.

Sentry is Fair Source under the FSL (Functional Source License). Note that Fair Source is not under the OSI umbrella, it becomes literally open source under the Apache 2.0 license after 2 years, and is practically open source before that except when you are a Sentry competitor. This license means that users can use Sentry and deploy it anywhere (even inside an enterprise ecosystem), but users are prohibited to sell deployed self-hosted Sentry as any kind of offering (SaaS or any other business model), and users are prohibited to be a direct competitor of Sentry by using Sentry's code that is FSL-licensed. The source code of Sentry and its surrounding service & libraries for self-hosted deployment are available on GitHub.

For further information on the FSL License, you can visit the fsl.software website or read the announcement blog post.

Previous
Developing Integrations
Next
Self-Hosted Releases & Upgrading
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").