Rollback Procedures

Quick Rollback

Docker Swarm keeps track of the previous service state. To roll back to the previous version:

docker service rollback dev_service-name

This reverts the service to its previous image and configuration.

Manual Rollback to a Specific Version

If you need to go back to a specific image tag:

1. Find the previous image in Harbor at https://harbor.ayinza.dev or check the git commit SHA

2. Update to the previous image:

   docker service update \
     --image harbor.ayinza.dev/library/service-name:previous-tag \
     --with-registry-auth \
     dev_service-name

3. Verify the rollback:

   docker service ps dev_service-name
   docker service logs -f dev_service-name --tail 50

Rollback an Entire Stack

If a full stack deploy went wrong, re-deploy with the previous version of the stack file:

# If you have the previous YAML (check git history)
git log --oneline /home/kaks/stacks/infrastructure.yml
git checkout HEAD~1 -- /home/kaks/stacks/infrastructure.yml
docker stack deploy -c /home/kaks/stacks/infrastructure.yml dev

Caution

Database migrations cannot be rolled back by simply reverting the service. If a deployment included database schema changes, you’ll need to handle the database separately. Always check if a service update includes migrations before rolling back.

Automatic Rollback Protection

Docker Swarm has built-in protection against failed updates. When a new container fails to start or its health check fails, Swarm will not kill the existing healthy container. The old working container keeps serving traffic while the new one is rejected.

This means a bad deployment does not break a running service — the previous healthy version stays in place.

# You can see this in action — failed tasks show "Shutdown" while the old one stays "Running"
docker service ps dev_api

This is one of the key safety nets of Docker Swarm: a failed update rolls back automatically, so a broken image push won’t take down a service that was working fine.

Tip

This is why you’ll sometimes see docker service ps showing multiple task entries — the failed new ones alongside the still-running old one. The old container was never removed because the new one couldn’t replace it.

Preventing Bad Deployments

• Check service logs immediately after deployment
• Use docker service ps to verify new containers are running and healthy
• Monitor the service for a few minutes after deployment
• If the service keeps restarting (crashloop), roll back immediately