Temporal Rainbow Deployment
A temporal rainbow deployment runs multiple worker code versions side by side during releases. You route new workflow runs to the new fleet while old runs finish intact. Teams set up this pattern to avoid replay errors on long jobs. Still, running many worker fleets at once often leads to broad, shared permissions. When every worker fleet shares wide database roles, one bad release risks live data. How a temporal rainbow deployment works in practice Temporal engines rely on deterministic code
Deployment Approval Gates: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A temporal rainbow deployment runs multiple worker code versions side by side during releases. You route new workflow runs to the new fleet while old runs finish intact. Teams set up this pattern to avoid replay errors on long jobs. Still, running many worker fleets at once often leads to broad, shared permissions. When every worker fleet shares wide database roles, one bad release risks live data.
How a temporal rainbow deployment works in practice
Temporal engines rely on deterministic code to replay past workflow events without error. If you swap code under a running job, the history replay will fail. A rainbow release fixes this by treating each code build as a distinct color. Instead of two fleets like blue and green, you run as many as needed.
To start, the deployment pipeline tags the new worker fleet with a build identifier. You can also assign the new worker fleet to a fresh task queue name. The server then sends all brand new workflow starts to this newest worker fleet. Meanwhile, older worker fleets stay online to process tasks for existing in-flight jobs.
Each older fleet only listens for tasks tied to its specific build tag. New code changes never touch old workflows that are still mid-flight. Once an old fleet has zero active workflows left, the platform team drains it. The team checks the task queue metrics and shuts down those idle compute nodes. This cycle repeats with every release, creating a shifting spectrum of active worker versions.
What native worker routing solves and what it leaves open
Native worker versioning solves the problem of breaking changes in long-running workflow code. Developers do not need to write complex branching checks inside their workflow definitions. Old jobs finish on the exact code version that started them weeks ago. New jobs get the latest features right away without waiting for old queues.
Still, this release model creates a large footprint of live worker fleets and humans. Every active color fleet needs database roles and API keys to run its activities. During an incident, engineers also log in to inspect queues, terminate jobs, or query databases. Native setup rules decide who can log in to the cluster or database.
Deployment Approval Gates: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Those static roles do not check what individual queries or commands do in flight. An engineer fixing a stuck red fleet might run an unreviewed drop statement. A bug in the yellow fleet might read raw customer emails or card numbers. Masking rules that rewrite matched fields in results are missing from standard role setups. Teams need command-level checks and field masking to keep multi-version worker fleets safe.
Managing fleet sprawl and database permissions
When five or six worker versions run at once, secret sprawl grows fast. Teams often copy the same static database password across every single worker deployment. If you rotate that key, you must update six live fleets at the same time. Missing even one old fleet will cause its remaining workflows to fail right away.
To avoid this pain, teams give workers and engineers wide, long-lived admin accounts. That shortcut keeps old workflows running, but it opens huge security gaps in production. A better approach separates workflow routing from how people and apps reach backend data. You should enforce strict controls on every query, regardless of which fleet sends it.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How is a rainbow deployment different from a blue-green deployment?
Blue-green setups only maintain two active worker versions at any given time. A rainbow setup supports three or more concurrent versions until old jobs finish.
When is it safe to shut down an old worker fleet?
You can shut down an old fleet when its open workflow count hits zero. Check the server metrics to confirm no pending retries remain on that version.
Do short workflows need a rainbow deployment strategy?
Short workflows that finish in seconds rarely need full rainbow version fleets. Rolling updates or simple backward-compatible patches work fine for fast jobs.