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

# Deployments

> Push published versions to production, roll back if needed, and manage the deployment lifecycle.

## Deployment Lifecycle

Deployment is the process of routing live traffic to a published policy version. LexQ tracks every deployment action for a complete audit trail.

```
Publish (DRAFT → ACTIVE)  →  Deploy (ACTIVE → LIVE)
                                    ↕
                              Rollback / Undeploy
```

## Deployment Actions

| Action       | Description                                                                                                                     |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| **Publish**  | Transitions a DRAFT version to ACTIVE. Locks the version — no more rule changes.                                                |
| **Deploy**   | Promotes an ACTIVE version to LIVE. This version now receives production traffic.                                               |
| **Rollback** | Reverts the group to its previously deployed version. Creates a new deployment record.                                          |
| **Undeploy** | Removes the live version. No traffic is processed until a new version is deployed.                                              |
| **Schedule** | Registers an ACTIVE version with a future effective start to deploy automatically at that time. One pending schedule per group. |

## Step-by-Step Deployment

### 1. Validate with Dry Run

Before publishing, always test your rules:

```bash theme={null}
lexq analytics dry-run --version-id <vid> --debug --mock \
  --json '{"facts": {"payment_amount": 150000, "customer_tier": "VIP"}}'
```

### 2. Publish

```bash theme={null}
lexq deploy publish --group-id <gid> --version-id <vid> --memo "Validated"
```

<Info>
  Publishing is never blocked by facts a rule references but the schema does not define. If the version has unregistered facts, the publish proceeds and they are surfaced as a warning — run `lexq facts unregistered` for the version to review them first.
</Info>

### 3. Deploy to Production

```bash theme={null}
lexq deploy live --group-id <gid> --version-id <vid> --memo "Go live — v3"
```

If the version's `effectiveFrom` is still in the future, an immediate deploy is rejected (`P-037`). Schedule it instead — the system deploys it automatically when the effective window opens:

```bash theme={null}
lexq deploy schedule --group-id <gid> --version-id <vid> --memo "Q4 pricing"
```

### 4. Monitor

```bash theme={null}
lexq deploy overview
lexq history list --group-id <gid>
lexq history stats --group-id <gid>
```

## Rollback

If something goes wrong after deployment:

```bash theme={null}
lexq deploy history --group-id <gid>
lexq deploy rollback --group-id <gid> --memo "Reverting due to high error rate"
```

## Undeploy

To stop all traffic processing for a group:

```bash theme={null}
lexq deploy undeploy --group-id <gid> --memo "Pausing for maintenance"
```

## Scheduled Deployment

A **Scheduled Deployment** arms an ACTIVE version whose `effectiveFrom` is in the future. When that time arrives, the system deploys it automatically — within one scheduler tick (≤60s) — and records the deployment in the ledger like any manual action, attributed to **System** with the schedule's memo.

Scheduling is explicit: publishing a future-dated version does **not** arm it by itself. Create the schedule from the console deploy dialog, `lexq deploy schedule`, or the `lexq_deploy_schedule` MCP tool.

**Integrity is sealed at scheduling.** The rule snapshot hash is captured when the schedule is created and re-verified at execution. If the version changed, was deleted, or the hash no longer matches, the schedule fails closed — status `FAILED` with a reason — instead of deploying something you didn't review.

**One pending schedule per group.** A second schedule request is rejected until the pending one is canceled.

**A pending schedule is canceled automatically** when a conflicting serving intent is expressed:

| Event                               | Pending schedule                    |
| ----------------------------------- | ----------------------------------- |
| Manual deploy / rollback / undeploy | Canceled                            |
| A/B test started                    | Canceled                            |
| Group archived                      | Canceled                            |
| User cancellation                   | Canceled (`lexq deploy unschedule`) |

Deleting the referenced version is **rejected** (`P-043`) while a schedule is pending — cancel the schedule first.

Every schedule keeps its full trail — who scheduled it, when it executed or why it was canceled or failed:

```bash theme={null}
lexq deploy schedules --format table
```

## Deployment History

Every deployment action is recorded with a timestamp, actor, memo, and the previous/new version:

```bash theme={null}
lexq deploy history --group-id <gid>
lexq deploy detail --deployment-id <deploymentId>
```

## Next Steps

<CardGroup cols={2}>
  <Card title="Dry Run" icon="flask-vial" href="/guides/dry-run">
    Pre-deployment validation for individual inputs.
  </Card>

  <Card title="Impact Simulation" icon="chart-bar" href="/guides/simulation">
    Impact validation against historical data before deploying.
  </Card>
</CardGroup>