What rollback means in Pystrano
Pystrano deployments are release-oriented. Each deploy creates a timestamped directory under releases and updates the current symlink to point at the newly deployed release.
In the current implementation, Pystrano does not expose a rollback CLI command. That means rollback is not a supported one-command workflow yet.
How release-oriented deployment helps
The release structure gives you a clear filesystem record of recent deploys:
/home/deploy/apps/example-django-app/releases/20260516120000
/home/deploy/apps/example-django-app/releases/20260516123000
/home/deploy/apps/example-django-app/current -> /home/deploy/apps/example-django-app/releases/20260516123000If you keep enough releases with keep_releases, an operator can inspect earlier release directories during incident response.
What rollback can and cannot fix
A code rollback can help when a bad release introduced application code, template, static asset, dependency, or service-startup problems. It cannot automatically repair database state, lost data, incompatible migrations, broken external services, expired credentials, server package issues, or infrastructure problems.
How to run rollback today
There is no real Pystrano rollback command to run today. Do not document or automate a rollback CLI command as if it exists.
For production use, create and test your own manual server procedure for selecting a previous release, repointing current, and restarting the service. Keep that runbook in your project operations docs until Pystrano ships an implemented and tested rollback command.
Database migration caveats
Django migrations are often the hardest part of rollback. If a deploy ran manage.py migrate, repointing application code to an older release may leave the old code running against a newer database schema.
Prefer migration strategies that are backward-compatible across at least one deploy window. Test rollbacks in staging with realistic data before relying on them in production.