Canary vs Blue/Green Deployment in Nomad for Safe Rollback After Schema Change

Goal: Ensure that a Nomad job can be rolled back to a previous version after an external database schema change without causing data corruption or version skew between old and new application instances.

Uncertainty: Canary deployments update a single task, which may leave the majority of tasks running the old code against a new schema, risking incompatibility, while Blue/Green deployments run a full parallel set, duplicating resources and still requiring external coordination to revert schema changes. It is unclear which approach better aligns with Nomad's update block settings (max_parallel, canary count) and external migration tooling to provide a safe rollback path.

Specific questions: Which deployment strategy minimizes the risk of version skew when the database schema cannot be reverted automatically? How do Nomad's update block parameters interact with each strategy to support a manual rollback after validation? What operational safeguards are needed to coordinate Nomad job rollbacks with external schema migration tools?