Skip to main content
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:
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 and 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.