> For the complete documentation index, see [llms.txt](https://docs.stackai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stackai.com/guides-and-quickstarts/releases-and-environments/deployments-and-approval-requirements.md). # Deployments and approval requirements Deployment stages let you release workflow versions through separate environments. Set approval requirements for each stage to control when a version becomes available. {% embed url="" %} ## Before you start A stage is a separate release destination, such as testing or production. Before changing approvals, agree who owns each stage and who will review it. Keep [Create environment variables](/guides-and-quickstarts/releases-and-environments/create-environment-variables.md) and [Assign and secure an environment](/guides-and-quickstarts/releases-and-environments/assign-and-secure-an-environment.md) separate from release approvals: the target stage also needs the correct configuration values. You need permission to configure deployment stages. Required reviewers must have access to the proposed workflow. ## Configure stage approvals Open Deployments and inspect Required Approvals for each stage. ![Required Approvals for deployment stages](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/pvuXoYPK8pdX9dkEiIcy/assets/g074-g074-01-policy.png) A zero-approval policy can deploy immediately, so use the approval requirements set by your team. ## Submit a version to a stage Save the candidate change and run the draft. ![Candidate draft test](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/NRpKbCmzgidCcxizLv52/assets/g074-g074-02-tested.png) Confirm the intended behavior before creating a deployment request. Select Create Pull Request and describe the change for the intended stage version. ![Deployment pull request description](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/qQhUTtKJOBIeCrOyI9oG/assets/g074-g074-03-request.png) Check the target environment and version before submitting. Open Deployments and confirm the new version is Pending. ![Pending deployment version](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/E8b1AWlmgHK63fnTX977/assets/g074-g074-04-pending.png) The previous deployed version remains active until the request meets the deployment requirements. ## Review the proposed version Have an authorized reviewer open View PRs for the pending version and select Review. ![View PRs and Review controls](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/JFGDGcXJCW5FhfwONiW9/assets/g074-g074-05-review-request.png) The reviewer should read the description before inspecting the candidate. Run the candidate in the review workspace and inspect its output. ![Candidate test in the review workspace](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/n49cpMmHCv3EsO1vDfxt/assets/g074-g074-06-reviewer-test.png) Review the proposed behavior without changing the working draft. Open Review Pull Request and inspect all Proposed Changes before accepting. ![Review Pull Request and Proposed Changes](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/2YtUYLW0IleOvHSroeio/assets/g074-g074-07-approved.png) Include configuration and connection changes, not only the most visible instruction edit. ## Verify the deployed version Return to Deployments and confirm the intended version is Deployed. ![Deployed version and stage details](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/Gu8OBjaZeHF1aSeGG6Xd/assets/g074-g074-08-deployed.png) Check Deployed By and the stage so you know which deployment changed. Open that stage's Deployment URL and inspect a response. ![Stage Deployment URL response](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/Hq8y3Wb6W4d2o0Qguk0v/assets/g074-g074-09-live.png) A successful check in one stage does not confirm the state of other stages. ## Recover a stage after a failed release Use **Redeploy** to return a stage to a version previously deployed to that same stage. This is a release action: an eligible redeployment updates the stage directly without creating a new approval request. It requires permission to update the project. Follow your team's incident ownership process before confirming it. 1. Record the affected stage, its current version, and the failing input. Locate a known good version in the stage's deployment history and review its configuration and previous test results. 2. Choose **Redeploy to \[stage]** for that historical version. In **Redeploy Version**, check both the version number and the stage, then choose **Redeploy**. 3. Confirm the success message and the stage's current version. Open that stage's **Deployment URL** in a fresh conversation, submit representative input, and inspect the response. Production redeployment also changes the published workflow version. 4. Record the incident and redeployment, then repair and test the working draft before the next release. Redeploying a stage is not a restoration of the editor draft, nor does it undo actions that earlier runs already performed in external services. Redeploy is unavailable for Draft, the version already active in the stage, a version never deployed to that stage, or a stage outside the project's configured stages. A pending request for the same target version and stage blocks redeployment. Have the release owner resolve that request deliberately rather than changing approval requirements to bypass it. If no eligible historical version is available, prepare a corrective version and use the normal release process. Escalate an unexpected error with the project, stage, version, and message through [Support and deployment diagnostics](/guides-and-quickstarts/personal-settings-and-support/support-and-deployment-diagnostics.md). ## Important behavior A pending request leaves the current stage version in place. Stages with no required approvals can deploy immediately. Check the stage URL when verifying a release. The editor draft may contain changes that have not reached that stage. --- # 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.stackai.com/guides-and-quickstarts/releases-and-environments/deployments-and-approval-requirements.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.