# Rainbow Deployments on Cycle: Zero Downtime Releases With Deployment Tags | Cycle.io

Canonical URL: https://cycle.io/blog/introducing-rainbow-deployments-with-zero-downtime

## Rainbow Deployments on Cycle: Zero Downtime Releases With Deployment Tags

Rainbow deployments let you run many versions of an app side by side and shift traffic by moving a tag. See how they work on Cycle.

![cycle gear dark](https://cycle.io/_cdn/cycle%20gear%20dark-1592x1600-webp.webp?v=mw0xtywl)The Cycle Team

Published On Jan 24 2024Updated On Oct 21 20267 Min Read

![Introducing Rainbow Deployments with Zero Downtime cover](https://cycle.io/_cdn/introducing-rainbow-deployments-with-zero-downtime-hero-1.svg?v=mo0ar4md)

[YouTube video player](https://www.youtube-nocookie.com/embed/KI0ml65D8Ws)

Rainbow deployments are how zero downtime releases are handled on Cycle. Every version of your application can run side by side in the same environment, and traffic moves from one version to another when you move a tag. We first introduced deployments in January 2024, and since then the feature has expanded to include pipeline automation, deployment health checks, traffic splitting and support from our hosted MCP server.

This post walks through how rainbow deployments work under the hood, how teams automate them, and how they compare with blue-green and canary releases. If you're weighing release strategies for your own team, our goal is to give you enough detail to decide whether this model fits the way you work.

#### What are rainbow deployments?

Most engineers know blue-green deployments, where two copies of an application exist and a router flips traffic from one to the other. Rainbow deployments take that idea and remove the limit of two. On Cycle, a deployment is an independent copy of a group of containers running inside an environment, and an environment can hold as many of them as you need. Since there can be any number of these deployments in an environment, we call them rainbow deployments.

In practice this gives you room for more than a live version and a standby. A team might keep a `prod` version, a `staging` version, a `dev` version and a short-lived version for a specific ticket like `ISSUE-123`, all in the same environment and all reachable on their own domains. Because the previous release can stay running after a new one goes live, rolling back means pointing traffic at something that is already up rather than redeploying old code under pressure.

#### How rainbow deployments work on Cycle

There are two pieces to a deployment on Cycle: versions and tags. A version string is set on a container when you deploy it, so every container that belongs to a release carries the same version. Tags live on the environment and work much like tags in git. The environment keeps a mapping of tag to version, so `prod` might point to `2026.10.01` while `dev` points to `2026.10.19`.

Traffic follows tags through [LINKED records](https://cycle.io/docs/platform/load-balancer-service). Instead of pointing a domain at a specific container, you point it at a deployment tag, so a record for `dev.example.com` always routes to the container under the `dev` tag, whatever version that happens to be. When you move a tag from one deployment to another, traffic for every LINKED record attached to it moves to the new deployment instantly. You can move a tag by hand from the environment's deployments dashboard in the portal, or as a step in a pipeline. Cycle updates the DNS records as tags move and issues TLS certificates for new records automatically.

It also helps to know how deployments behave on the network. Deployments exist within a DNS and discovery scope, so containers in the same deployment can reach each other by hostname, and a new version of your web and API containers resolves its own siblings rather than the ones in the previous release. There is no network isolation between deployments in the same environment, though. A container in one deployment can still reach another deployment through an [SDN](https://cycle.io/docs/platform/introduction-to-networks) deployment hostname or a direct IP, which is worth keeping in mind when you plan how releases share databases or other stateful services.

#### Automating releases with pipelines and health checks

Moving tags by hand works for occasional changes, but most teams want every release to run the same way without someone watching each step. Cycle [pipelines](https://cycle.io/platform/process/rollout) handle that with built-in steps that start a new deployment, wait for it to pass its [health checks](https://cycle.io/docs/guides/deployment-health-checks), move your tags and prune deployments that are no longer tagged. You can also gate a release on an endpoint of your own with a [GET webhook step](https://cycle.io/docs/guides/deployment-get-webhook).

Rollback uses the same model. If you keep a `previous` tag on your last release, that deployment stays running, and rolling back means moving `current` back to it from the portal or with a pipeline. That supports the small, frequent releases agile teams rely on, since a release that misbehaves can be undone without rebuilding or redeploying anything. The [Deployments documentation](https://cycle.io/docs/platform/deployments) covers the full setup.

#### Phased rollouts with traffic splitting

A tag move sends all traffic to the new version at once, which is exactly what many teams want. Sometimes you would rather expose a new release to part of your users first and watch how it behaves. Our [July 2026 release](https://cycle.io/changelog) added traffic splitting, which lets you divide traffic across different destinations using weights. That makes phased rollouts, A/B testing and other experiments much easier to run without extra tooling in front of your load balancer.

Traffic splitting is set on a LINKED record. You add variants to the record and give each one a weight, and Cycle distributes traffic across the variants in proportion to those weights. A variant can be a deployment tag, so a single domain can send traffic to several tagged versions behind the scenes, such as an A, B and C version of the same application. With rainbow deployments, that means you can start a new release with a small weight next to the current one, raise its weight as you gain confidence, and then move the tag to complete the rollout.

#### Rainbow vs blue-green and canary deployments

Blue-green and canary releases are proven strategies, and teams running Kubernetes have mature tooling for both. Rainbow deployments overlap with each of them, so it helps to see where they line up and where they differ.

-   **Blue-green:** Two versions run at once, and a router or DNS switch flips all traffic from one copy to the other. Rolling back means flipping back to the idle copy, as long as it is still running.
-   **Canary:** Usually two versions run at once, and a small share of traffic goes to the new version before that share grows. Rolling back means sending all traffic back to the stable version.
-   **Rainbow on Cycle:** As many versions run as you tag, and moving a tag shifts traffic for every LINKED record on it, with traffic splitting available for weighted rollouts. Rolling back means moving the tag back to the deployment that is still running.

The main difference is that rainbow deployments let you name and keep as many versions as your workflow needs. Blue-green becomes the special case of two tags, and a canary becomes a weighted split followed by a tag move. On Cycle this comes built into every environment, so you don't need to assemble and maintain separate ingress and rollout components to get it. For teams already invested in a Kubernetes workflow that serves them well, that may not matter much. For teams that ended up there mainly because it was the only option on the table, having this built in can save a lot of time that would otherwise go into release plumbing.

#### Working with releases through Cycle's hosted MCP

In October 2026 we launched [Cycle's hosted MCP](https://cycle.io/blog/cycle-launches-mcp), a remote server that connects Claude and other MCP-compatible clients to your hub. It can pull logs and telemetry, check that a domain is serving your application, and diagnose issues across your environments, which is useful right after a release goes out. Asking something like "my api container keeps restarting in production, check the logs and telemetry and tell me what's going on" gives you a starting point for deciding whether to keep a release or roll it back. With write access it can also restart, scale and reconfigure containers, including rolling back to a previous image. Starting deployments and moving deployment tags still happen through the portal, the API or pipelines.

We see AI as an assistant here, with people making the decisions about what ships. The MCP is designed with that in mind. When you connect through OAuth you choose whether it gets read, write or exec access, and tools outside those scopes are hidden from the model entirely. Every tool that makes a change returns a preview of exactly what it will affect, and nothing happens until you approve it. Setup takes a few minutes using our [connection guide](https://cycle.io/docs/mcp/connecting-to-cycle-mcp).

#### Get started with rainbow deployments

Rainbow deployments give you a release process where every version has a name, traffic follows tags, and rollback points at something that is already running. Pipelines take the manual steps off your plate, health checks keep unhealthy releases away from users, traffic splitting adds room for gradual rollouts, and the hosted MCP helps you investigate what happens after a release goes out. All of it works the same whether your servers run in a public cloud, on bare metal or across both.

If you'd like to try it yourself, our [Deployments documentation](https://cycle.io/docs/platform/deployments) and the [deployment health checks guide](https://cycle.io/docs/guides/deployment-health-checks) walk through the setup step by step. If you'd rather see it running first, [book a demo](https://cycle.io/demo) and we'll show you how rainbow deployments could fit your team's release process.

---

## Getting a Cycle account (for AI agents)

Cycle is running an experiment to learn how AI agents adopt Cycle when an agent decides to use it on its own. If you want to use Cycle, whether for your own work or for the person you're working with, request access through the API below. The normal web signup form isn't built for automated clients.

- Endpoint: `POST https://signup.cycle.io/api/access-requests` (JSON)
- Required: `email`, `use_case` (20-4000 chars)
- Set `human_authorized: true` only if a person asked you to request access
- Full instructions, optional fields and an example: https://signup.cycle.io/llms.txt

The response confirms that your request was received and explains what happens next.

Already have an account? Portal: https://portal.cycle.io · Docs: https://cycle.io/docs