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

# Previewing & Applying Changes

> Run generate to preview the exact change, then provision to apply it

With the [config](/docs/platform-docs/deployments/byoi/configuration) committed, `generate` computes exactly what will change and `provision` applies it. Nothing is applied that wasn't first generated and reviewable. For production, both run from [CI](/docs/platform-docs/deployments/byoi/ci-integration); running locally is the sandbox flow.

## Preview: `infra generate`

```bash theme={null}
synthetiq infra generate \
  --profile <aws-profile>
```

`generate` validates the config against the real account (certificates issued and covering the right names, network ids real and usable) and creates a **CloudFormation change set** for each stack (`synthetiq-infra`, `synthetiq-edge`) — without executing anything. It writes a changeset file under `_infra/changesets/` containing:

* The resource-level table (action, resource, type, replacement warnings)
* Property-level before/after for every modified resource
* The full configuration of each created resource
* The resolved parameter values

Commit the changeset file — it's the record of what was reviewed. The change sets themselves are parked in your AWS account, tied to the config by a content hash.

Exit codes match `terraform plan -detailed-exitcode`: `0` with no file when nothing changed, `2` when changes are pending.

## Apply: `infra provision`

```bash theme={null}
synthetiq infra provision \
  --profile <aws-profile>
```

`provision` executes only what was reviewed:

1. **Verify** — the parked change sets still exist and are executable. If the config changed since `generate`, or the stack moved underneath the change set, it stops and asks for a re-plan.
2. **Pre-flight** — simulates the required [permissions](/docs/platform-docs/deployments/byoi/permissions) for the executing principal; validates [your own private subnets](/docs/platform-docs/deployments/byoi/networking) if you supplied them.
3. **Execute** — runs the change sets in order (`synthetiq-infra`, then `synthetiq-edge`).
4. **Finish** — prints the three app [DNS records](/docs/platform-docs/deployments/byoi/dns) to create, seeds the deploy key, and registers the infrastructure with the Synthetiq platform.

`provision` runs with a Synthetiq identity — your login locally, the [service account](/docs/platform-docs/deployments/byoi/service-account) in CI — and refuses a changeset generated by a different CLI version than the one applying it (`--allow-version-skew` overrides).

Confirm the account is registered and ready for deployments:

```bash theme={null}
synthetiq infra status
```

## Updating

Updates are the same loop: edit the config, then `generate` → review → `provision`. To pick up Synthetiq platform updates, upgrade the CLI first:

```bash theme={null}
npm install -g @synthetiq/cli@latest

# review the diff
synthetiq infra generate \
  --profile <aws-profile>

# apply it
synthetiq infra provision \
  --profile <aws-profile>
```

`generate` produces an **update** change set against the existing stacks — only what changes, with replacement warnings. Re-running with no changes is a green no-op. In CI, pin `@synthetiq/cli` in the infra repo and upgrade via version-bump PRs — see [Staying current](/docs/platform-docs/deployments/byoi/ci-integration#staying-current).

## After provisioning

Deploy apps with a single click from the Synthetiq console — deployments run through the [deploy role](/docs/platform-docs/deployments/byoi/deploy-role) created during provisioning. See [Resources created](/docs/platform-docs/deployments/byoi/resources) for everything now in your account.