> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/workflows-in-release/rainbow-deployments.md).

# Rainbow deployments

{% hint style="info" %}
This is an opt-in Enterprise feature. Please contact us at <support@release.com> if you want to enable rainbow deployments on your account.
{% endhint %}

Rainbow deployments are an extension of the popular blue-green deployment pattern.

* With blue-green deployments, you have two copies of your production environment, "blue" and "green". Either the blue or green environment is the active production environment at any given time. When you deploy changes, you deploy them to the environment that is not currently active and then switch the recently changed environment to active. This means that your development and production environments remain closely mirrored by default.
* With Release, you have easy access to unlimited environments, so you can extend the blue-green pattern to infinite colors of the rainbow. Each deployment happens in a **namespace**, which is a copy of your production environment. Each namespace gets a color, and you can have as many colors as you need.

You can think of these deployments as lanes on a highway: Two lanes are better than one, but infinite lanes are better than two. Let's say you are currently running version 1 of your software in the "blue" environment and you deploy version 2 to the "green" environment. You switch "blue" over to your main environment and direct user traffic there, while keeping "green" running to complete a few asynchronous jobs that still need to complete. Now you discover a problem with version 2 and deploy a hotfix. If you're stuck with only two environments, blue and green, you have to choose between killing the jobs running on green or pushing new code directly to your live environment. If you have infinite colors available, you can keep both the previous environments running while starting a new environment, "yellow", for example.

![Rainbow environments](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-6a73734afa45be2efda0df69a24677b658c296cc%2Frainbow-deployments-overview.png?alt=media\&token=b3d8a07f-c6b2-4ab5-b91d-2c08ed8d6583)

We use rainbow deployments internally at Release, so we'll be happy to help you decide if they are a good fit for you and advise you on using them effectively in your specific case.

## How to use rainbow deployments

After the rainbow deployment feature has been activated in your account, you will be able to configure rainbow deployments through your Application Template file. Note that it only works for **permanent** environments, not ephemeral ones. You'll specify a timeout period and how many active environments you want, as described in the next section.

If you activate rainbow deployments in an environment, you'll see a rainbow icon to indicate that it is active for that environment, as shown below.

![rainbow icon](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-80f1b0149bd899cc56a19e8005768e9f2a1d7192%2Frainbow-deployments-rainbow-icon.png?alt=media)

This will also activate the **Namespaces** tab, where you can see a number of subenvironments, each with its own color, as shown below.

![Namespaces tab](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-fa14ef793b899a90dcbece338f9d575ff6299d1b%2Frainbow-deployments-namespaces-tab.png?alt=media\&token=068fba7d-6ecb-4c61-acd8-d85aed546efe)

A new production deployment will automatically go to a new namespace, get a new color, and immediately become the active namespace in that environment. The previous namespace will stay alive for a configured timeout period.

This timeout period is useful in case you have long-running jobs or other tasks that need to complete before the environment disappears.

* After the timeout, the old namespace will be removed.
* If you redeploy exactly the same build, it will still create a new namespace and expire the previous one, but the color won't change.

## Configuring rainbow deployments

To turn rainbow deployments on in a specific environment, add the following block to your Application Template YAML file:

```yaml
rainbow_deployment_configuration:
    type: infinite
    termination_threshold: 180.minutes
```

* The `type` value defines the kind of rainbow deployment. Currently, we only support `infinite` for this value, which means that there is no limit to how many namespaces can be created in an environment.
* The `termination_threshold` value specifies the timeout for environments to stay alive after a new environment is deployed. You can set this in seconds, minutes, or hours, and you should choose a value greater than the longest-running job or process in that namespace to avoid losing any in-progress work.

Note that the `termination_threshold` is applied when the namespace is **created**, so if you update it and redeploy your build, then your existing namespace will still terminate after the previously defined value has elapsed.

## State and state changes for rainbow deployments

A namespace can take on one of several states. These are:

* **Active**: The currently active environment, also indicated by an arrow in the list of namespaces.
* **Pending**: The namespace is initializing with your configuration. This state should only last a few seconds before moving into **Activating**.
* **Activating**: The namespace that will be active next. As soon as it is ready, it will become active and the previously active namespace will become **Inactive**.
* **Inactive**: Any previously active namespace that has not yet been destroyed. You'll see a countdown timer next to inactive namespaces indicating when they are due for termination.
* **Destroyed**: Any previously active namespace that has passed its `termination_threshold`. You can still see information such as the build number, configuration version, and creation time for these environments.

There are two icons with arrows to the left of the namespaces that show the currently active environment and (if applicable) the next environment that will activate. You can see these in the image below.

![statuses](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-489054857df563e5dfabe9aa3ecdae2763875dd8%2Frainbow-deployments-statuses.png?alt=media\&token=d4fd2fdb-c287-4285-8bfa-a0d3a05315e7)

Inactive environments show a timer indicating when they will be destroyed. You can see this below.

![expiring](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-07d0ecea94af46b25ea01447728d8cc870bd3851%2Frainbow-deployments-expiring.png?alt=media\&token=ca88feeb-8f1c-4aca-8b18-bfb5c973665f)

## Namespace details

By clicking on the color for any namespace, you'll see a Namespace Details page that shows the same information (name, time until removal, deployment ID, and version) as you can see on the overview page, as well as a list of instances running in that namespace.

![namespace details](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-22757471f1e0f85586f1d0739ba5b1280abca034%2Frainbow-deployments-namespace-details.png?alt=media\&token=9ab4119b-35af-4ef6-acb7-e9fc79f0dcaa)

## What lives inside rainbow environments?

In an ideal world, rainbow deployments mean creating infinite copies of all resources that make up a given environment. In reality, it is not practical to have infinite copies of resources such as your production database or Apache Kafka instances. Therefore, resources like this often live "outside" of this setup.

You'll have to structure your systems carefully so that you don't, for example, have conflicts when several expired but not destroyed environments are competing for the same external resource.

## Choosing colors

In case you wonder how the colors for environments are chosen, we use the short Git hash (conveniently, a six-character hex number) and translate it directly to a hex color code.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.release.com/reference-documentation/workflows-in-release/rainbow-deployments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.