Self-Hosted Releases & Upgrading
Sentry cuts regular releases for self-hosting to keep it as close to sentry.io as possible. We decided to follow a monthly release schedule using the CalVer versioning scheme, with a primary release on the 15th of each month. We don't patch old versions, but if a bug is bad enough we may cut an out-of-cycle point release, which, like our regular monthly releases, is a snapshot of the latest versions of all of our components. You can find the latest release over at the releases section of our self-hosted repository.
Why CalVer?
In short, this is to keep the self-hosted Sentry as close to the live version hosted at sentry.io. There are more details for the curious over at our blog post announcing the switch.
Warning
CalVer is optimized for continuous deployment, not long-term stability. We recommend that you upgrade regularly, as we do in our SaaS environment.
We encourage everyone to regularly update their Sentry installations to get the best and the most recent Sentry experience.
To upgrade, all you need to do is download or check out the version of self-hosted repository you want, replace your existing folder's contents with that, and then run ./install.sh
.
Configuration Updates
We may have some updated configuration, especially for new features, so always check the example config files under the sentry directory and see if you need to update your existing configuration. We do our best to automate critical configuration updates, but you should always check your configs during upgrades.
Before starting the upgrade, we shut down all the services and then run some data migrations, so expect to have some downtime. There is an experimental --minimize-downtime
option to reduce the downtime during upgrades. Use this at your own risk and see the pull request it was implemented in for more information.
Warning
There are certain hard-stops you need to go through when upgrading from earlier versions. Please read the hard-stops section below for a list.
If you downloaded self-hosted repository using Git clone, the upgrade commands should look like this:
# Assuming your destination upgrade version is 24.3.0
VERSION="24.3.0"
git fetch
git checkout ${VERSION}
sudo ./install.sh
We have three hards stops that you need to go through in order to pick up significant database changes:
- If you are coming from a version prior to
9.1.2
, you first need to upgrade to9.1.2
and follow the next steps:Copied<your.sentry.version> -> 9.1.2 -> 21.5.0 -> 21.6.3 -> 23.6.2 -> latest
- If you are coming from
9.1.2
, you first need to upgrade to21.5.0
and follow the next steps:Copied<your.sentry.version> -> 21.5.0 -> 21.6.3 -> 23.6.2 -> latest
- If you are coming from a version prior to
21.6.3
, you first need to upgrade to21.6.3
:Copied<your.sentry.version> -> 21.6.3 -> 23.6.2 -> latest
- If you are coming from a version prior to
23.6.2
, you first need to upgrade to23.6.2
:
<your.sentry.version> -> 23.6.2 -> latest
Any other case (23.6.2+
), you should be able to upgrade to the latest version directly. We'd recommend you skip 23.7.0
to avoid issues around database migrations and the django 3 upgrade.
We provide nightly builds from the master branch of the self-hosted repository for each new commit for Sentry, and all of the supporting projects:
These builds are usually stable, but you may occasionally hit a broken version as these versions are not guaranteed to be deployed to sentry.io first. There is also no guarantee that you will be able to do a clean upgrade to later versions without losing any data. Use the nightly builds at your own risk.
The
23.11.0
release will remove thesentry run smtp
worker process. This worker was not part of the standard self-hosted configuration, but could be used in custom deployments.The
24.1.2
release will change the memcached backend fromdjango.core.cache.backends.memcached.MemcachedCache
todjango.core.cache.backends.memcached.PyMemcacheCache
. This will require changing theCACHES
setting in yoursentry.conf.py
file in a manner similar to what is seen here. In particular, theOPTIONS
API forPyMemcacheCache
is different from that ofMemcachedCache
, and may require changes depending on how it has been configured.
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").