Deploy Strategies

Mentat supports three deployment strategies. Each service declares its strategy in the YAML config. Strategy can be overridden at deploy time via --strategy.

Configuration

deploy:
  strategy: rolling        # rolling | blue-green | canary
  max_unavailable: 1       # max replicas down at once (rolling)
  health_timeout_secs: 10  # wait time for health check
  auto_revert: true        # rollback on failure
  canary_percent: 10       # % traffic to canary (canary only)
  standby_secs: 600        # blue standby time (blue-green only)

All fields have sensible defaults. A service with no deploy block uses rolling with max_unavailable=1 and auto_revert=true.

Rolling

Default strategy. Upgrades replicas in batches of max_unavailable. If any batch fails and auto_revert is true, automatically rolls back to the previous image.

flow
1. Start batch of new replicas (size = max_unavailable)
2. Wait health_timeout for them to come up
3. Stop corresponding old replicas
4. Repeat until all replicas upgraded
5. If failure → auto rollback to previous image
usage
mt deploy spacing-guild --image registry.dune/spacing-guild:v2

Best for: Stateless Rust unikernels (Spacing Guild, Harvester, StreamForge). With ~8ms Firecracker boot, rolling updates are nearly instant.

Blue-Green

Spins up a complete "green" set of replicas with the new image. Once all are healthy, traffic switches instantly. The "blue" set stays on standby for standby_secs before cleanup.

flow
1. Start N new replicas (green) with new image
2. Wait for all green replicas to be healthy
3. Switch traffic from blue → green (instant)
4. Blue stays alive for standby_secs (default 600s)
5. If failure → mt rollback switches back to blue
usage
mt deploy jarvis --image jarvis-api:v2
# if something goes wrong:
mt rollback jarvis

Best for: .NET services with DB schema changes (Jarvis, Bene Gesserit). Allows instant rollback without re-deploying.

Canary

Routes a percentage of traffic to the new image. The deploy stays in "canary" state until the operator explicitly promotes or aborts.

flow
1. Calculate canary replicas: ceil(replicas * canary_percent / 100)
2. Start canary replicas with new image
3. Wait for operator decision:
   → mt canary promote <service>  (roll out to all)
   → mt canary abort <service>    (revert canary replicas)
usage
# Deploy canary (10% of traffic)
mt deploy streamforge --image streamforge:v2 --strategy canary

# Monitor, then decide:
mt canary promote streamforge   # go full
mt canary abort streamforge     # revert

Best for: Risky changes to critical services (StreamForge). Lets you validate in production before committing.

Rollback

Works with any strategy. Reverts to the previous image recorded in the deployment history. Can be triggered manually or automatically via auto_revert.

usage
mt rollback <service>