> ## Documentation Index
> Fetch the complete documentation index at: https://to11.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Promotion Policies

> Govern how configuration changes move from one environment into the next.

A promotion policy sets the conditions a change must meet before it can become live in an environment. Each environment has its own policy, applied separately for prompts and for routing rules. The policy belongs to the *destination* environment — it governs what's allowed to move *into* production, not what leaves staging.

## How promotion works

You promote a change from the surface where it lives:

* **Prompts** — the **Releases** tab in the prompt editor.
* **Routing rules** — the **Environments** tab on a routing rule's detail page.

From there you pick the version to promote, choose the target environment, and enter a reason for the change. to11 evaluates the target environment's policy before the change goes live. If the policy is satisfied, the version becomes the one that environment serves. If the policy requires approval, the promotion is recorded as a pending release that waits for sign-off — see [Release approvals](/docs/deploy/release-approvals).

## Policy options

A promotion policy can require any of the following:

| Option                          | What it enforces                                                                                                                                                 |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Required source environment** | The version being promoted must already be live in a specific environment first — for example, only allow production promotions of versions that ran in staging. |
| **Minimum dwell time**          | A version must have been live in its source environment for a minimum number of hours before it's eligible to promote.                                           |
| **No rollback**                 | Block promotions that would move the environment back to an older version within a look-back window (24 hours by default).                                       |
| **Requires approval**           | A promotion lands as a pending release that a reviewer must approve before it serves traffic.                                                                    |
| **Separation of duties**        | The approver must be someone other than the person who requested the promotion. Turning this on also requires approval.                                          |

## Configuring a policy

Promotion policies are set per environment in the dashboard at **Project → Settings → Environments**, in the **Promotion policy** section of the environment editor.

<Note>
  Editing a promotion policy requires the `env:policies:manage` permission. See [Roles & permissions](/docs/platform/roles-and-permissions).
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Release approvals" icon="badge-check" href="/docs/deploy/release-approvals">
    Require sign-off before a change applies.
  </Card>

  <Card title="Scheduled changes" icon="calendar-clock" href="/docs/deploy/scheduled-changes">
    See changes queued to apply later.
  </Card>
</CardGroup>
