> ## 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.

# Deployments and runs

> Understand how Automate.ax plans, authorizes, publishes, and executes project code.

A deployment publishes all `*.automation.ts` files in a project directory as
one project runtime. A run is one durable execution context created from a
trigger event.

## Deployment flow

Run the CLI from the directory containing `automate.config.ts`:

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

Automate.ax then:

1. Finds and builds every `*.automation.ts` file.
2. Runs the programs in planning mode to discover descriptions, triggers,
   actions, account bindings, and required permissions.
3. Prompts for missing integration authorization.
4. Configures required event sources.
5. Publishes the project runtime and activates the deployment.

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.

## Atomic project snapshots

A successful deployment becomes the project's single active snapshot. All
automation files are built and activated together, so a project never mixes
files from two successful deployments.

Each automation's relative source path is its identity in that snapshot. Move
or rename a file only when you intend to replace that automation identity.

## From event to actions

When an active trigger accepts an event, Automate.ax creates an isolated
execution context for that automation and event. The runtime repeatedly
composes the program, schedules actions whose signal dependencies are ready,
records their terminal outcomes, and resumes composition as new outputs become
available.

Independent actions can execute concurrently. Dependent actions execute only
after their required signals materialize. See [Signals](/concepts/signals) and
[Actions](/concepts/actions).

## Durability and retries

Action outcomes and dependencies are stored durably. If an executor stops,
Automate.ax can resume from recorded work instead of treating the whole program
as an in-memory process.

Thrown execution failures are retried by the platform before becoming a failed
action outcome. Because a provider may accept a request before a worker learns
the result, actions should use provider-supported idempotency where available
and should not assume several separate actions form one transaction.

## Deploying code changes

New trigger events use the active deployment. Work already executing on a
published version can finish there; later resumptions verify that the current
code still matches recorded durable action identities and dependencies.

Keep action call order and literal structure deterministic so in-flight work
remains compatible. When a change intentionally replaces an automation's
durable structure, consider whether existing executions can still resume
safely before deploying it.