Multi-instance releases
Learn about multi-instance releases and how they differ between apps and classic apps.
Organizations can manage the releases of protected apps, classic apps, and workflows across multiple deployment instances. You can specify which release version of an app or workflow is available on each deployment that's configured with Source Control. This is particularly useful if you want to test a newer version on a staging or development instance before promoting to production.
To enable or disable multi-instance releases, navigate to Settings > Source control > Edit settings and toggle Enable multi-instance releases. Click Save.
Apps vs. classic apps
Multi-instance releases work slightly differently for apps and classic apps.
Both approaches publish different release versions to different instances, and both use per-instance manifests to control what's live. They differ in how each release is stored and created. For complete instructions, refer to the apps and classic apps and workflows guides.
| Apps | Classic apps | |
|---|---|---|
| Release format | A git tag pointing to a standalone commit that captures the app at that version. | A release artifact, which is a zipped snapshot of the app. |
| Storage in the repository | Git tags. Protected app source is stored in the apps-v2/ directory. | Zipped artifacts in dist/apps/<app-uuid>/<version>.zip. |
| Effect on repository size | Minimal. Release commits reuse files already in the repository. | Grows with each release artifact. |
| Create a release | Tag a version from the Version History panel. | Open a release pull request. |
| Publish a release to an instance | Set the version in the instance's manifest. | Set the version in the instance's manifest. |
| API management | Not supported. | Supported through the Retool API. |