Rebuilding Marten Projections Without Downtime with Wolverine 6.51 Warm-up Nodes
Wolverine 6.51 adds a warm-up node role for blue/green deployments. New nodes join the cluster only to rebuild new projection versions in Marten or Polecat, without handling messages or subscriptions. Combined with versioned projections and a side-effect gate, teams can catch up read models before switching traffic. This is a practical path to zero-downtime releases for event-sourced systems.
Key points
- Set opts.Durability.NodeRole to NodeRole.Warmup on green nodes; the default is NodeRole.Serving.
- Warm-up nodes never lead, never run event subscriptions, and only receive projection agents no serving node declares.
- Bump the Version on a Marten projection so the new version gets its own tables and progress tracking.
- Keep warm-up pods out of the load balancer selector; health check endpoints must still respond.
- Upgrade serving nodes to a Wolverine version that understands node roles before deploying the first warm-up node.
- Use GateSideEffectsBehindPriorVersion (Marten 9.39.1+) so a new projection version does not re-fire side effects from history.
Wolverine 6.51 introduces a warm-up node role aimed at event-sourced systems that need to revise projections during a release without exposing half-built read models. A warm-up node joins the cluster, but it never leads, handles no messages, runs no event subscriptions, and is assigned only the projection agents that changed. Those agents run in rebuild mode, so side effects stay suppressed while they follow the live stream and resume from their own committed progress after a restart.
The feature relies on Marten's versioned projections, which give each version its own tables and progress tracking. Once the new version is caught up, the nodes are restarted as serving and moved behind the load balancer. Wolverine enforces the role only inside its runtime, so application-level hosted services and direct HTTP traffic still need explicit checks. Serving nodes must run a Wolverine version that understands node roles before the first warm-up node is deployed.
Real-world use
- Rebuilding a read model in a multi-tenant event-sourced system with millions of events, then switching traffic without downtime.
- Shipping a release that adds a new event type to a Wolverine service, so projections are prepared before any new node handles commands.
- Running blue/green deployments on Kubernetes, where green pods join the cluster early but receive traffic only after catch-up.
Why it matters
Projection changes in event-sourced systems no longer have to mean downtime or half-built read models. The payoff depends on careful handling of side effects, load balancer rules and the ordering of node upgrades.