Restate follows Semantic Versioning. The server persists compatibility markers which enable it to detect incompatible data versions. However, you should be careful to follow supported version migration paths and perform data backups when performing software upgrades.Documentation Index
Fetch the complete documentation index at: https://docs.restate.dev/llms.txt
Use this file to discover all available pages before exploring further.
Version compatibility
Consult the release notes for the specific details of any new version when planning upgrades. As with all critical infrastructure changes, we recommend that you always verify the upgrade path in an isolated test environment first.
x.y to x.(y+1) while retaining all persisted data and metadata. You must not skip minor version upgrades, i.e. go directly from x.y to x.(y+2), as it may bypass necessary data store migrations required for preserving forward compatibility.
Since later versions may introduce new functionality that is on by default, it’s crucial that you baseline your configuration on the release from which you will be upgrading. If you haven’t done so already, be sure to capture the effective runtime configuration of your existing Restate cluster on the original version, and use this configuration initially when you upgrade.
If you encounter any issues with a new version, you can downgrade a Restate installation to the latest patch level of the previous minor version. For example, you can safely rollback the Restate server version from x.y.0 to x.(y-1).z if you encounter any issues. However, rollback is only supported as long as you have not used any new features exclusive to the newer version. You should enable new features in the server configuration only after you have verified the overall system behaviour on the new version. Going back to more than one minor version behind to the most recent version used with the data store is not supported.