Partial stack redeploy failure in Portainer Docker Compose Stacks: rollback behavior

Portainer Stacks maintain repeatable Docker Compose development environments from Compose files stored in Git repositories or entered in the UI. An unresolved question concerns what happens when a stack redeploy fails partway, such as when an updated image reference is invalid, and whether the previous environment is restored automatically.

Documented behavior indicates that Portainer does not provide a built-in automatic rollback to the prior stack revision when a redeploy fails. Stack revision history is retained in the UI, but returning to an earlier state requires triggering a new deploy from that revision rather than performing an atomic rollback. Failed updates may leave containers, networks, or volumes in a partially updated state.

Behavior can vary between Portainer Community Edition and Business Edition, and Kubernetes manifest stacks follow different update semantics than Docker Compose stacks. The exact failure-handling path for a specific installed version should be verified against the relevant Portainer documentation.

Does Portainer automatically restore the previous Docker Compose stack revision after a partial redeploy failure, or does the endpoint remain in a partially updated state until manual intervention? Is the only recovery path to redeploy the last known-good Compose file from the revision history, or does any edition offer an atomic rollback operation? How do CE and Business Edition differ in stack update failure handling for Docker Compose environments?