Deploy Strategies
Choose the right deployment strategy for your WorkClaw agents. Compare blue/green, rolling, and batched approaches to find the best fit for your team's risk tolerance.
What is a deploy strategy?
A deploy strategy determines how WorkClaw rolls out new builds to your runtime hosts. The strategy controls the sequence, speed, and safety mechanisms used during a deployment. Choosing the right strategy balances deployment speed against risk -- faster rollouts reach all users sooner, but slower rollouts give you more time to catch problems.
Which strategies does WorkClaw support?
WorkClaw offers three deploy strategies:
| Strategy | Best for | Downtime | Rollback speed |
|---|---|---|---|
| Blue/Green | Teams that want instant cutover with full rollback | Zero | Instant |
| Rolling | Gradual rollouts across many runtime hosts | Zero | Fast |
| Batched | Large fleets needing staged validation | Zero | Fast per batch |
How do I choose a strategy?
Consider these factors:
- Fleet size -- if you run a single runtime host, blue/green is the simplest choice. For larger fleets, rolling or batched strategies reduce blast radius.
- Risk tolerance -- blue/green gives you the fastest rollback because the previous environment stays warm. Rolling and batched strategies progressively replace hosts, which means partial rollback is possible.
- Resource budget -- blue/green requires double the runtime capacity during deployment (both old and new environments run simultaneously). Rolling and batched reuse existing capacity.
How do I change my deploy strategy?
Navigate to Admin > Settings > Deploy Strategy and select your preferred approach. The change takes effect on the next deployment. You can also set the strategy per-deployment when triggering from the API.
What happens during deployment failures?
All strategies include automatic health checks after each phase. If a health check fails, WorkClaw pauses the deployment and notifies admins. You can then choose to retry, roll back, or investigate using the Monitoring dashboard. Orphaned containers from failed deployments are automatically cleaned up.