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

> ## Agent Instructions
> Automate.ax automations are TypeScript programs.
> Use Bun for installation and command examples.
> Use Automate.ax for the product name and automate.ax for the package, CLI, and domain.
> Treat documented public APIs as current; do not invent transitional or deprecated names.

# Deploy a project

> Publish every automation in a project and set its parameters and integration accounts.

The deploy command runs a TypeScript 7 type check before building. Automate.ax encodes many authoring rules in its types, while deployment adds build and planning checks that need the complete project. Pass `--skip-typecheck` only when you need to bypass the local type check.

From the directory containing `automate.config.ts`, run:

```bash theme={null}
bunx automate.ax deploy
```

The command:

1. Runs TypeScript 7 with `--noEmit` unless you pass `--skip-typecheck`.
2. Builds every `*.automation.ts` file.
3. Plans each file's triggers and actions.
4. Opens **Parameters & Accounts** when project-specific values or account assignments are needed.
5. Configures event sources and activates the deployment.

The project dependency and command-line tool must agree with the server's runtime protocol. If deployment reports an incompatible protocol, update both to `automate.ax@latest`, rebuild, and redeploy.

Planning rejects structures the runtime cannot execute safely, including an action that cannot resolve to exactly one causal context boundary. Successful bundling does not replace planning or the earlier TypeScript type check.

The previous deployment remains active unless the new deployment succeeds. After success, `.automate/deployment.md` records the deployed project, automation files, deployment identity, and trigger details such as HTTP URLs.

## Set parameters and accounts

By default, deployment opens a focused **Parameters & Accounts** page. Set values declared by the automation, assign saved accounts, or connect new accounts without exposing credentials to the command line. Pass `--cli-authorization` to complete the same setup in the terminal.

A non-interactive or `--json` deployment exits with `DEPLOYMENT_SETUP_REQUIRED`. The error includes the deployment ID, setup URL, unresolved parameters, unsatisfied service bindings, and resume command. Complete setup in the browser, then resume the same deployment without rebuilding:

```bash theme={null}
bunx automate.ax deployment authorize dep_123
```

Pass `--no-open` to print the setup URL without opening a browser.

## Inspect deployment history

Use `deployment list` to browse deployment history and `deployment show` to inspect one result:

```bash theme={null}
bunx automate.ax deployment list --project "Customer operations" --status failed
bunx automate.ax deployment list --since 2026-08-01T00:00:00Z --limit 25
bunx automate.ax deployment show dep_123
```

`deployment list` resolves one project. Without `--org` or `--project`, it uses a nearby project config or asks you to choose. Pass `--org` to limit project selection to one organization.

`--status` accepts `planning`, `awaiting_authorization`, `configuring`, `publishing`, `succeeded`, `failed`, or `cancelled`. `--since` and `--until` accept timestamps such as `2026-08-01T00:00:00Z`.

## Replace an in-progress deployment

If another deployment is planning, awaiting authorization, or configuring, the command-line tool offers to cancel it. Pass `--cancel-existing` to do so non-interactively. You cannot cancel a deployment after publishing begins.

Cancel a specific deployment with:

```bash theme={null}
bunx automate.ax deployment cancel dep_123 --yes
```

A project can have only one in-progress deployment. API clients must explicitly cancel it before starting another.

## Change parameters and account assignments

Open **Parameters & Accounts** in the web app. You can update declared parameter values or choose replacement accounts. Automate.ax runs planning again and republishes the active code with the new settings.

Agents can use explicit, non-secret account identifiers instead. Run `automation list --project <project> --json` to find service and binding pairs, then `accounts --org <organization> --json` to find eligible account IDs. Save the assignments in a JSON file:

```json bindings.json theme={null}
[
  {
    "serviceId": "google",
    "binding": "support",
    "accountId": "intacct_123"
  }
]
```

Redeploy the active artifact and plans:

```bash theme={null}
bunx automate.ax deployment redeploy --project "Customer operations" --bindings bindings.json --json
```

If an account still needs authorization, open the returned authorization URL and run `deployment authorize <deployment-id>` afterward. The binding file contains platform account IDs, not provider credentials. Pass an empty array to assign every required account in the browser.