> 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/rolling-deployments.md).

# Rolling deployments

Release automatically handles most aspects of rolling deployments for you. This means that when you push code changes, your applications will not face any downtime.

A rolling update does not apply code changes to all of your nodes at once, but rather works as follows:

* Nodes in your cluster are terminated one at a time and replaced with new nodes running the new version of your software.
* While each node is down, traffic is routed only to the healthy nodes. For a short while, some users may see the new version of your software while others still see the old version.
* The update process for each node is started only after the previous node comes up and is confirmed healthy.

As you can see in the diagram below, during a rolling update, the majority of nodes are available to serve traffic at all times.

![Rolling Updates Diagram](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-da5876dc5004ab1d7ceb65d5af64759483133e48%2Frolling-deployments-diagram.png?alt=media\&token=a2b0ef83-f88c-46b2-85e7-cf3cbf55bf0c)

You can read more about how rolling deployments work [in the Google Cloud documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/updating-apps), but note that Release handles this for you automatically and there is no need for you to follow the steps listed on that page.

## Considerations when using rolling deployments

While rolling deployments work well for many use cases, they may not always be appropriate. For example, you may need to be sure that all your users see the same version of your software. With rolling updates, it can be difficult to know which version of your application users are accessing at a given point in time.

Database migrations can also be tricky with rolling deployments. If you need to add or rename a database column, for example, you'll need to be careful with your application code and the order your changes are applied to ensure that your database logic can handle both the old and the new application code.

## Blue-green and rainbow deployments

An alternative to rolling deployments is blue-green deployments. With this model, you have two copies of your environment, one "blue" and one "green". Only a single environment is user-facing at any given time. When you deploy changes, you deploy them to the non-user-facing environment, and only once all changes are completed and confirmed working do you switch all users to the new environment simultaneously.

This can result in cleaner updates, but it also means that any bugs or issues will affect all of your users. Traditionally, the blue-green deployment model is also associated with higher costs, as you have to maintain two full instances of your complete infrastructure.

### Rainbow deployments

Because Release gives you environments as primitive building blocks, you can extend the blue-green deployment model further. Instead of having only two environments, you can add as many "colors" as you need, having a completely new environment for every change. We call these rainbow deployments.

Please contact us if you would like to use rainbow deployments with your account, as this is currently a manual feature that we activate for you.


---

# 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/rolling-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.