--- title: "Releases & Upgrading" description: "Learn how to upgrade your self-hosted Sentry installation and stay up to date with the latest releases" url: https://develop.sentry.dev/self-hosted/releases/ --- # Self-Hosted Releases & Upgrading Sentry cuts regular releases for self-hosting to keep it as close to [sentry.io](https://sentry.io) as possible. We decided to follow a monthly release schedule using the [CalVer](https://calver.org/#scheme) versioning scheme, with a primary release on the [15th of each month](https://github.com/getsentry/self-hosted/blob/704e4c3b5b7360080f79bcfbe26583e5a95ae675/.github/workflows/release.yml#L20-L24). 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](https://github.com/getsentry/self-hosted/releases/latest) over at the [releases section of our self-hosted repository](https://github.com/getsentry/self-hosted/releases/). ##### Why CalVer? In short, this is to keep the self-hosted Sentry as close to the live version hosted at [sentry.io](https://sentry.io). There are more details for the curious over at our [blog post announcing the switch](https://blog.sentry.io/2020/06/22/self-hosted-sentry-switching-to-calver). ##### Warning CalVer is optimized for continuous deployment, *not* long-term stability. We recommend that you upgrade regularly, as we do in [our SaaS environment](https://sentry.io/pricing/). ## [Upgrading](https://develop.sentry.dev/self-hosted/releases.md#upgrading) We encourage everyone to regularly update their Sentry installations to get the best and the most recent Sentry experience. 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](https://github.com/getsentry/self-hosted/issues/607) for more information. We assume you've cloned the self-hosted repository, so checkout the version you want to upgrade to (25.7.0 as an example). ```bash git fetch git checkout 25.7.0 ``` ##### Warning If you upgrade infrequently, it's less likely that upgrading to the latest version will work. Please refer to [Hard Stops](https://develop.sentry.dev/self-hosted/releases.md#hard-stops) for how to incrementally upgrade to more recent versions. We may have some updated configuration, especially for new features, so always check the example config files under the [sentry directory](https://github.com/getsentry/self-hosted/blob/master/sentry/) 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. If you have a `.env.custom` file, make sure to copy new environment variables from the `.env` file into the `.env.custom` file before running the install script. Finally, to upgrade, run `./install.sh`. Upon completion, run `docker compose up --wait` (or if you have `.env.custom` file, run `docker compose --env-file .env --env-file .env.custom up --wait`). ### [Hard Stops](https://develop.sentry.dev/self-hosted/releases.md#hard-stops) When upgrading one must upgrade to **each** hard stop to pick up significant database changes. These are the hard stops that one needs to go through: * 9.1.2 * 21.5.0 * 21.6.3 * 23.6.2 (execute `COMPOSE_PROJECT_NAME=sentry_onpremise docker compose down --rmi local --remove-orphans` before you upgrade to > 21.12.0) * 23.11.0 * 24.8.0 * 25.5.1 Versions to avoid upgrading to: * 23.7.0 (issues around database migrations and the Django 3 upgrade) As an example if one wants to go from `22.8.0` to `24.2.0` one needs the following upgrade path: ```bash # example (initial: 22.8.0) -> 23.6.2 -> 23.11.0 -> 24.2.0 ``` ### [Versions with known issues](https://develop.sentry.dev/self-hosted/releases.md#versions-with-known-issues) This section lists known issues with specific versions of the self-hosted Sentry. You may upgrade to these versions if you are not affected by any of these issues. * 24.12.0 has issues with login ([#3473](https://github.com/getsentry/self-hosted/issues/3473)) * 24.12.1 has issues with login with orgs having hardware 2FA enabled ([#3473](https://github.com/getsentry/self-hosted/issues/3473)) ## [Nightly Builds](https://develop.sentry.dev/self-hosted/releases.md#nightly-builds) We provide nightly builds from the [master branch of the self-hosted repository](https://github.com/getsentry/self-hosted/) for each new commit for [Sentry](https://github.com/getsentry/sentry), and all of the supporting projects: * [Snuba](https://github.com/getsentry/snuba) * [Relay](https://github.com/getsentry/relay) * [Symbolicator](https://github.com/getsentry/symbolicator) * [Vroom](https://github.com/getsentry/vroom) * [Uptime Checker](https://github.com/getsentry/uptime-checker) * [Taskbroker](https://github.com/getsentry/taskbroker) 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](http://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.** ## [Breaking Changes](https://develop.sentry.dev/self-hosted/releases.md#breaking-changes) * The `23.11.0` release will remove the `sentry 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 from `django.core.cache.backends.memcached.MemcachedCache` to `django.core.cache.backends.memcached.PyMemcacheCache`. This will require changing the `CACHES` setting in your `sentry.conf.py` file in a manner similar to what is seen [here](https://github.com/getsentry/self-hosted/commit/9936376f4e933781feaae85e0071ef72c7f1c03f). In particular, the `OPTIONS` API for `PyMemcacheCache` is different from that of `MemcachedCache`, and may require changes depending on how it has been configured.