# Publish and activate fixed app releases

A shared release is an immutable snapshot of an app's definition, parameters, model policy, connector configuration, and provisioned workflow recipes, paired with a compatible renderer. Use it when users should run a fixed experience while you continue editing the draft.

Publishing and activating are separate actions. **Publish release** captures a release. **Activate release** selects which saved release serves the shared deployment. Publishing alone does not change the active deployment.

## Publish

1. Save and verify the intended app definition.
2. Review Parameters, model choice, connector selections, and workflows.
3. Open **Versions → Shared releases**.
4. Review the displayed definition and parameter revisions.
5. If offered more than one, choose the **Renderer version**.
6. Choose **Publish release** and wait for confirmation.

A compatible admitted renderer is required. If none is available, ask the platform administrator to provide one. If the app changes during capture, Strive refuses to publish the stale selection; refresh state and review the source again.

## Activate or roll back

Choose **Activate release** on the desired history entry. The active entry is marked **Active**. Use **Open active release** to inspect the selected experience.

To roll back, activate an earlier saved release. This changes subsequent admissions to that release's configuration. A run that already selected a release retains its original pinned recipe, parameters, model policy, and configuration. Editing the draft, activating another release, or deactivating does not rewrite an admitted run.

## Deactivate and recover

Choose **Deactivate** to stop the shared release deployment from accepting new release-backed work. History remains available for later activation. Deactivation is not a history deletion or a rollback of finished output.

If the app or deployment changed, **Refresh state** and review your selection again. If a response could not be confirmed, **Retry same request** repeats the original operation rather than creating a second publication. Do not change the selection and then treat it as the same uncertain request.

Current ownership, access, lifecycle, and artifact availability remain checked even for an immutable release. A release does not freeze permissions or make a trashed app usable. Earlier releases without captured workflow content cannot substitute current draft recipes for workflow-backed execution.