Add zero-downtime deployment support for Docker Compose stacks using docker-rollout

[ElyasAsmad]

Is your feature request related to a problem? Please describe

Yes. When deploying or updating Docker Compose stacks in Portainer, services are recreated using the standard Docker Compose flow. For web applications or APIs behind a reverse proxy, this can still introduce a short period of downtime while the old container is stopped and the new container is starting.

This is especially noticeable for single-server Docker Compose setups where users do not want the complexity of Kubernetes, Docker Swarm or Nomad, but still want safer deployments for production workloads.

Currently, users who manage Compose stacks through Portainer may need to handle zero-downtime deployment manually outside Portainer using custom scripts or CLI commands. This reduces the value of Portainer as the central deployment UI.

Describe the solution you'd like

I want to propose to Portainer to support zero-downtime deployment strategy for Docker Compose stacks, potentially by integrating with or adopting the behavior of Docker Rollout:

https://docker-rollout.wowu.dev/

Docker Rollout is a Docker Compose zero-downtime deployment CLI. Instead of running:

docker compose up -d <service>

it runs:

docker rollout <service>

The rollout process works by:

1. Starting a new container for the updated service.
2. Waiting for the new container to become ready, preferably using Docker healthchecks.
3. Routing traffic to the new healthy container through a reverse proxy such as Traefik or nginx-proxy.
4. Removing the old container after the new one is ready.

In Portainer, this could be exposed as an option when updating/redeploying a stack, for example:

Deployment strategy:

• Standard Compose redeploy
• Zero-downtime rollout

Possible configuration options:

• Enable rollout per service
• Rollout timeout
• Wait time if no healthcheck is defined
• Wait-after-healthy duration
• Optional pre-stop hook for draining old containers
• Warning/validation if the service uses container_name or direct ports, since these can prevent multiple containers from running at the same time
• Recommendation to use a reverse proxy and Docker healthchecks

This would be useful for users running production apps on a single Docker host (like our use case) with Docker Compose and Traefik/nginx-proxy.

Describe alternatives you've considered

Before proposing this, we've also considered some other alternatives that might serve the purpose we need:

1. Use Docker Swarm
   Docker Swarm supports rolling updates, but not every user (and us) wants to convert a simple single-node Docker Compose setup into Swarm mode. For many small teams and self-hosted deployments, Swarm adds operational changes that may not be necessary.

2. Use Kubernetes
   Kubernetes provides rolling deployments but it is a bit too heavy for small single-server deployments or teams that choose Docker Compose for simplicity.

3. Use external deployment scripts
   Users can manually install Docker Rollout and run rollout commands outside Portainer. However, this means Portainer is no longer the single source of truth for stack deployment operations.

4. Use CI/CD only
   A CI/CD pipeline can call docker rollout, but this still leaves Portainer unaware of the deployment strategy and limits users who prefer to deploy directly from the Portainer UI.

5. Manual scale-up / scale-down
   Finally, users can manually scale services and remove old containers but this is error-prone and not ideal for repeatable production deployments.

Additional context

Docker Compose is widely used for single-server production deployments together with reverse proxies such as Traefik However, the default Compose redeployment flow can briefly interrupt traffic especially for time-critical applications (like our trading platform).

Docker Rollout solves this gap for many Compose users with a simple CLI-based approach. By having similar functionality available directly in Portainer, I believe it would make Portainer more useful for production Docker Compose workflows without requiring users to adopt Swarm or Kubernetes.

This feature could start as an optional advanced deployment mode for Compose stacks rather than replacing the existing redeploy behavior.