> 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/stages-of-workflows.md). # Stages of workflows There are currently four stages in the Release workflow: ## The build stage The build stage in Release is when the `docker build` commands are run. It's the first step that must take place before any other stages can be executed. You can't configure the build stage in Release. ## The setup stage The setup stage is the beginning of the lifecycle of an environment. In this stage, Release issues `docker run` commands, creates the infrastructure and objects that are necessary for the fully functioning environment to be constructed, and then deploys the code. This initial code deployment takes place during the setup stage so that the environment is fully functional when the setup stage is complete. The setup stage must run at least once before the patch stage, and again whenever the Application Template or Environment Variables Template is changed to apply changes. The setup stage can be run manually to rebuild an existing environment that is out of sync with the Release version, which may occur due to some unforeseen failure or restart in Kubernetes. ## The patch stage The patch stage is only run when the build stage and setup stage have been completed. This is the stage at which new code is deployed or updated. A patch can be triggered from a Git push to the same tracking branch for the environment, or it can be triggered manually using the **Deploy** button on the Environment Details page or the Build Details page. The patch stage is somewhat like a traditional "deploy" stage, when code is updated and jobs are run. The key difference between Release's patch stage and a traditional deploy stage is that the patch stage does not need to do any of the heavy lifting of setting up necessary infrastructure, as this will have been completed in the setup stage. For example, in the patch stage, there is no need to initialise databases or create load balancers. ## The teardown stage The teardown stage is run when an environment is either expired or deleted. You can use the teardown stage to remove any extra infrastructure, permanent entries, or storage created elsewhere that Release is not aware of. For example, you can use the teardown stage to destroy infrastructure created with Terraform or Pulumi, or to delete or drop tables in a shared database or storage system. ![](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-76d475e6df15b31bbb2f236850165eeab9019b5b%2FWorkflow%20stages.jpg?alt=media) --- # 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/stages-of-workflows.md?ask=&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.