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

# Deployment Requests

> Create, review, and manage Deployment Requests for gated tenants from the CLI

Some tenants require a **Deployment Request** — a reviewable request that must collect a minimum number of approvals — before a release can deploy to them. See [Deployment Requests](https://docs.xano.com/enterprise/enterprise-features/tenant-center.md#deployment-requests) for the full concept and the equivalent console workflow. This page covers managing them from the CLI.

> [!NOTE]
>
> These commands require a workspace ID, either from your profile or via the `-w` flag. A tenant only accepts Deployment Requests if it has **Require Deployment Request** enabled (`required_reviewers > 0`) — see [`xano tenant create`/`edit`](https://docs.xano.com/xano-cli/tenants#create-a-tenant).

## List Deployment Requests

Terminal

```bash theme={null}
xano tenant_deploy_request list
xano tenant_deploy_request list --tenant TENANT_NAME
xano tenant_deploy_request list --status pending
```

Each request shows its ID, title, status, target tenant, release, author, and current approval count against the required minimum. Use `-o json` for the full JSON response.

## Get Request Details

Terminal

```bash theme={null}
xano tenant_deploy_request get REQUEST_ID
```

Returns the request's full detail: title, description, status, tenant, release, base release (the tenant's live release when the request was created), author, approval/comment activity, and resolution details once closed or deployed.

## Create a Request

Terminal

```bash theme={null}
xano tenant_deploy_request create TENANT_NAME --release v1.0 --title "Deploy v1.0 to Production"
```

| Flag | Description |
| - | - |
| `TENANT_NAME` | Target tenant (required, positional) |
| `-r, --release` | Release name to request deployment of (required) |
| `--title` | Request title (required) |
| `-d, --description` | Request description |
| `-w` | Workspace ID |
| `-o` | Output format: `summary` or `json` |

> [!NOTE]
>
> Creating a request doesn't deploy anything. The release only reaches the tenant once the request is approved (see [`set_status`](#approve-request-or-decline-a-request)) and, if **Allow Approve & Deploy** isn't enabled on the tenant, manually deployed.

## Edit a Request

Terminal

```bash theme={null}
xano tenant_deploy_request edit REQUEST_ID --title "Updated title" -d "Updated description"
```

Only the request's author can edit it, and only while it's in an editable status (`draft`, `pending`, or `changes_requested`).

## Link a New Release

If the release you want to deploy changes after a request is opened — for example, you need to fix something a reviewer flagged — link the new release as a revision rather than opening a new request:

Terminal

```bash theme={null}
xano tenant_deploy_request revision REQUEST_ID --release v1.1
```

Linking a new revision keeps the request's discussion and history intact, but marks any existing approvals as outdated — reviewers need to approve the new revision before it can deploy.

## Approve, Request Changes, or Close a Request

Terminal

```bash theme={null}
# Approve (counts toward the tenant's required minimum)
xano tenant_deploy_request set_status REQUEST_ID --status approve
xano tenant_deploy_request set_status REQUEST_ID --status approve --comment "LGTM"

# Request changes (comment required)
xano tenant_deploy_request set_status REQUEST_ID --status changes_requested --comment "Please add a rollback plan"

# Close (withdraw or decline) — final; a closed request can't be reopened
xano tenant_deploy_request set_status REQUEST_ID --status closed --comment "No longer needed"
```

| Flag | Description |
| - | - |
| `--status` | The transition to apply: `approve`, `changes_requested`, or `closed` |
| `--comment` | Comment to attach to this transition (required for `changes_requested`) |
| `-w` | Workspace ID |
| `-o` | Output format: `summary` or `json` |

> [!NOTE]
>
> You can't approve or request changes on a request you authored yourself. Once a request has enough distinct approvals to meet the tenant's required minimum, it becomes eligible to deploy — automatically if the tenant has **Allow Approve & Deploy** enabled, otherwise via `xano tenant deploy_release` or a manual deploy in the console. Approvals are single-use: once a request's approval has been used to deploy a release, redeploying it needs a fresh approval.

## Bypass Review

If the tenant has **Allow Authorized Deployment Bypass** enabled and you hold the **Tenant Center Deploy Bypass** permission, you can deploy a request without collecting approvals:

Terminal

```bash theme={null}
xano tenant_deploy_request bypass REQUEST_ID --reason "Emergency hotfix, on-call approved verbally"
```

| Flag | Description |
| - | - |
| `--reason` | Justification for the bypass (required) |
| `-w` | Workspace ID |
| `-o` | Output format: `summary` or `json` |

> [!WARNING]
>
> Bypassing skips review entirely and deploys immediately. Every bypass is logged and visible in the tenant's [Logs](https://docs.xano.com/enterprise/enterprise-features/tenant-center.md#logs) — reserve this for genuine emergencies, not routine deploys.


## Related topics

- [Tenant Center](https://docs.xano.com/enterprise/enterprise-features/tenant-center.md)
- [Tenants](https://docs.xano.com/xano-cli/tenants.md)
- [Deployment](https://docs.xano.com/deployment.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.