# Workflow Commands
Source: https://docs.chain.link/cre/reference/cli/workflow
Last Updated: 2026-04-30

> For the complete documentation index, see [llms.txt](/llms.txt).

The `cre workflow` commands manage workflows throughout their entire lifecycle, from local testing to deployment and ongoing management.

> **NOTE: Global flags**
>
> All `cre` commands support [global flags](/cre/reference/cli#global-flags), including `--env`, `--public-env`, `--target`, `--project-root`, `--verbose`, and `--non-interactive`.

## `cre workflow build`

Compiles a workflow to a raw WASM binary and writes it to a file. Unlike `cre workflow deploy`, this command only compiles — it does not upload artifacts or register the workflow onchain. Use this command to produce and inspect a build artifact independently, for example in a CI/CD pipeline where you want to build once and promote the same binary across environments.

**Usage:**

```bash
cre workflow build <workflow-folder-path> [flags]
```

**Arguments:**

- `<workflow-folder-path>` — (Required) Path to the workflow folder (e.g., `./my-workflow`)

**Flags:**

| Flag                 | Description                                                                                                                 |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| `-o, --output`       | Output file path for the compiled WASM binary (default: `<workflow-folder>/binary.wasm`)                                    |
| `--skip-type-checks` | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds |

**Example:**

```bash
cre workflow build ./my-workflow
```

**Example output:**

```
Compiling workflow...
✓ Workflow compiled successfully
  Binary hash: 0x3a7f...c21b
✓ Build output written to ./my-workflow/binary.wasm
```

The binary hash printed here matches the hash shown during `cre workflow deploy`. You can also compute it explicitly with [`cre workflow hash`](#cre-workflow-hash).

For CI/CD usage, see [Deploying Workflows](/cre/guides/operations/deploying-workflows#cicd-pipeline-integration).

***

## `cre workflow simulate`

> **NOTE: Authentication required**
>
> Running this command requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to verify you're
> logged in, or run `cre login` to authenticate. See [Creating Your Account](/cre/account/creating-account) and [Logging
> in with the CLI](/cre/account/cli-login) for further details.

Compiles your workflow to WASM and executes it in a local simulation environment. This is the core command for testing and debugging your workflow.

**Usage:**

```bash
cre workflow simulate <workflow-name-or-path> [flags]
```

**Arguments:**

- `<workflow-name-or-path>` — (Required) Workflow folder name (e.g., `my-workflow`) or path (e.g., `./my-workflow`). When run from the project root, you can use just the folder name. The CLI looks for a `workflow.yaml` file in the workflow directory.

**Flags:**

| Flag                      | Description                                                                                                                                                                                                                                                                      |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--broadcast`             | Broadcast onchain write transactions (default: `false`). Without this flag, a dry run is performed                                                                                                                                                                               |
| `-g, --engine-logs`       | Enable non-fatal engine logging                                                                                                                                                                                                                                                  |
| `--non-interactive`       | Run without prompts; requires `--trigger-index` (see the line below) and inputs for the selected trigger type                                                                                                                                                                    |
| `--trigger-index <int>`   | Selects which handler to run (0-based position). If your workflow has multiple handlers, `0` is the first, `1` is the second, etc. Required with `--non-interactive`                                                                                                             |
| `--http-payload <string>` | HTTP trigger payload as JSON string or path to a JSON file. File paths are resolved relative to the directory where you ran the command. For HTTP triggers only                                                                                                                  |
| `--evm-tx-hash <string>`  | Transaction hash (`0x...`) containing the event that triggered your workflow. For EVM log triggers only                                                                                                                                                                          |
| `--evm-event-index <int>` | Which log/event within the transaction to use (0-based position). If the transaction emitted multiple events, `0` is the first, `1` is the second, etc. For EVM log triggers only                                                                                                |
| `--limits <string>`       | Production limits to enforce during simulation: `default` (embedded prod limits), a path to a limits JSON file (e.g. from `cre workflow limits export`), or `none` to disable. See [Testing Production Limits](/cre/guides/operations/understanding-limits) (default: `default`) |
| `--skip-type-checks`      | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds                                                                                                                                                      |

**Examples:**

- Basic simulation

  ```bash
  cre workflow simulate ./my-workflow --target local-simulation
  ```

- Broadcast real onchain transactions

  ```bash
  cre workflow simulate ./my-workflow --broadcast --target local-simulation
  ```

- Non-interactive mode with HTTP trigger

  ```bash
  # If your HTTP trigger handler is the first handler in your workflow, use --trigger-index 0
  cre workflow simulate my-workflow --non-interactive --trigger-index 0 --http-payload '{"key":"value"}' --target staging-settings
  ```

- Non-interactive mode with EVM log trigger

  ```bash
  # If your EVM log trigger handler is the second handler in your workflow, use --trigger-index 1
  # --evm-event-index 0 means you want the first event from that transaction
  cre workflow simulate my-workflow --non-interactive --trigger-index 1 --evm-tx-hash 0x420721d7d00130a03c5b525b2dbfd42550906ddb3075e8377f9bb5d1a5992f8e --evm-event-index 0 --target staging-settings
  ```

> **NOTE: Dry run by default**
>
> By default, `cre workflow simulate` performs a **dry run** for onchain write operations. It simulates the transaction to confirm it would succeed, but does not broadcast it to the network. This results in a successful log with an empty transaction hash (`0x`). To send a real transaction, use the `--broadcast` flag.

## `cre workflow deploy`

> **NOTE: Deployment access required**
>
> Deploying workflows requires Early Access approval. Run `cre account access` to check your status or submit a request. See [Requesting Deploy Access](/cre/account/deploy-access).

**While you wait:** Continue building and simulating workflows using [`cre workflow simulate`](/cre/guides/operations/simulating-workflows).

> **NOTE: Authentication required**
>
> Running this command requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to verify you're
> logged in, or run `cre login` to authenticate. See [Creating Your Account](/cre/account/creating-account) and [Logging
> in with the CLI](/cre/account/cli-login) for further details.

Deploys a workflow to the Workflow Registry — the onchain contract where workflows are enrolled so the Chainlink DON knows they exist and should run them. This command compiles your workflow, uploads the artifacts to the CRE Storage Service, and submits a registration transaction to the registry. Use [`cre registry list`](/cre/reference/cli/registry) to see which registry your organization is configured to use.

**Usage:**

```bash
cre workflow deploy <workflow-name-or-path> [flags]
```

**Arguments:**

- `<workflow-name-or-path>` — (Required) Workflow folder name (e.g., `my-workflow`) or path (e.g., `./my-workflow`)

**Flags:**

| Flag                 | Description                                                                                                                   |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `-o, --output`       | Output file for the compiled WASM binary encoded in base64 (default: `"./binary.wasm.br.b64"`)                                |
| `--wasm`             | Path to a pre-built WASM binary (skips compilation). Use with [`cre workflow build`](#cre-workflow-build) for CI/CD pipelines |
| `--config`           | Override the config file path from `workflow.yaml`                                                                            |
| `--no-config`        | Deploy without a config file                                                                                                  |
| `--unsigned`         | Return the raw transaction instead of sending it to the network                                                               |
| `--yes`              | Skip the confirmation prompt and proceed with the operation                                                                   |
| `--skip-type-checks` | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds   |

**Examples:**

- Deploy workflow

  ```bash
  cre workflow deploy my-workflow --target production-settings
  ```

- Deploy and save the compiled binary to a custom location

  ```bash
  cre workflow deploy my-workflow --output ./dist/workflow.wasm.br.b64
  ```

- Deploy using a pre-built binary (skips compilation)

  ```bash
  # Build once
  cre workflow build ./my-workflow

  # Deploy with the pre-built binary
  cre workflow deploy ./my-workflow --wasm ./my-workflow/binary.wasm --target production-settings
  ```

> **NOTE: Deploying over a paused workflow**
>
> If you deploy an update to a workflow that is currently paused, the CLI will complete the update and then print a warning: `Your workflow is paused and has been updated`. The workflow remains paused after the update — run `cre workflow activate` to resume it.

For more details, see [Deploying Workflows](/cre/guides/operations/deploying-workflows).

## `cre workflow activate`

> **NOTE: Authentication required**
>
> Running this command requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to verify you're
> logged in, or run `cre login` to authenticate. See [Creating Your Account](/cre/account/creating-account) and [Logging
> in with the CLI](/cre/account/cli-login) for further details.

Changes the workflow status to active on the Workflow Registry contract. Active workflows can respond to their configured triggers.

**Usage:**

```bash
cre workflow activate <workflow-name-or-path> [flags]
```

**Arguments:**

- `<workflow-name-or-path>` — (Required) Workflow folder name (e.g., `my-workflow`) or path (e.g., `./my-workflow`)

**Flags:**

| Flag         | Description                                                     |
| ------------ | --------------------------------------------------------------- |
| `--unsigned` | Return the raw transaction instead of sending it to the network |
| `--yes`      | Skip the confirmation prompt and proceed with the operation     |

**Example:**

```bash
cre workflow activate ./my-workflow --target production-settings
```

For more details, see [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows).

## `cre workflow pause`

> **NOTE: Authentication required**
>
> Running this command requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to verify you're
> logged in, or run `cre login` to authenticate. See [Creating Your Account](/cre/account/creating-account) and [Logging
> in with the CLI](/cre/account/cli-login) for further details.

Changes the workflow status to paused on the Workflow Registry contract. Paused workflows will not respond to triggers.

**Usage:**

```bash
cre workflow pause <workflow-name-or-path> [flags]
```

**Arguments:**

- `<workflow-name-or-path>` — (Required) Workflow folder name (e.g., `my-workflow`) or path (e.g., `./my-workflow`)

**Flags:**

| Flag         | Description                                                     |
| ------------ | --------------------------------------------------------------- |
| `--unsigned` | Return the raw transaction instead of sending it to the network |
| `--yes`      | Skip the confirmation prompt and proceed with the operation     |

**Example:**

```bash
cre workflow pause ./my-workflow --target production-settings
```

> **CAUTION: Pausing stops trigger execution**
>
> When you pause a workflow, it will no longer respond to any triggers. Ensure this is intentional before pausing production workflows.

For more details, see [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows).

## `cre workflow delete`

> **NOTE: Authentication required**
>
> Running this command requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to verify you're
> logged in, or run `cre login` to authenticate. See [Creating Your Account](/cre/account/creating-account) and [Logging
> in with the CLI](/cre/account/cli-login) for further details.

Deletes a workflow from the Workflow Registry.

**Usage:**

```bash
cre workflow delete <workflow-name-or-path> [flags]
```

**Arguments:**

- `<workflow-name-or-path>` — (Required) Workflow folder name (e.g., `my-workflow`) or path (e.g., `./my-workflow`)

**Flags:**

| Flag         | Description                                                     |
| ------------ | --------------------------------------------------------------- |
| `--unsigned` | Return the raw transaction instead of sending it to the network |
| `--yes`      | Skip the confirmation prompt and proceed with the operation     |

**Example:**

```bash
cre workflow delete ./my-workflow --target production-settings
```

> **CAUTION: Destructive operation**
>
> This command **permanently deletes the workflow**. The `--yes` flag bypasses the confirmation prompt for this destructive operation. Use with caution.

For more details, see [Deleting Workflows](/cre/guides/operations/deleting-workflows).

## `cre workflow list`

> **NOTE: Authentication required**
>
> Running this command requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to verify you're
> logged in, or run `cre login` to authenticate. See [Creating Your Account](/cre/account/creating-account) and [Logging
> in with the CLI](/cre/account/cli-login) for further details.

Lists workflows deployed for your organization across registries. Deleted workflows are hidden by default.

**Usage:**

```bash
cre workflow list [flags]
```

**Flags:**

| Flag                  | Description                                                                       |
| --------------------- | --------------------------------------------------------------------------------- |
| `--include-deleted`   | Include workflows in `DELETED` status                                             |
| `--output <string>`   | Output format. Use `json` to print a JSON array to stdout for scripting use cases |
| `--registry <string>` | Filter results by a specific registry ID from your user context                   |

**Examples:**

- List all workflows

  ```bash
  cre workflow list
  ```

- List all workflows including deleted ones

  ```bash
  cre workflow list --include-deleted
  ```

- Export workflow list as JSON

  ```bash
  cre workflow list --output json > workflows.json
  ```

**JSON output fields:**

| Field             | Description                                                                  |
| ----------------- | ---------------------------------------------------------------------------- |
| `name`            | Workflow name                                                                |
| `workflowId`      | Workflow ID                                                                  |
| `ownerAddress`    | Workflow owner address                                                       |
| `status`          | Current workflow status                                                      |
| `registry`        | Registry ID, or the workflow source when no registry match is available      |
| `contractAddress` | Workflow registry contract address, when available for the resolved registry |

**Example JSON output:**

```json
[
  {
    "name": "my-workflow",
    "workflowId": "00ab...1234",
    "ownerAddress": "0x1234...abcd",
    "status": "ACTIVE",
    "registry": "onchain:ethereum-mainnet",
    "contractAddress": "0x5678...ef01"
  }
]
```

***

## `cre workflow get`

> **NOTE: Authentication required**
>
> Running this command requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to verify you're
> logged in, or run `cre login` to authenticate. See [Creating Your Account](/cre/account/creating-account) and [Logging
> in with the CLI](/cre/account/cli-login) for further details.

Shows metadata for the workflow configured in `workflow.yaml`. The command reads the workflow name for the selected `--target`, searches the CRE platform for matching workflow metadata, and filters results to the workflow's configured `deployment-registry` by default.

**Usage:**

```bash
cre workflow get <workflow-folder-path> [flags]
```

**Arguments:**

- `<workflow-folder-path>` — (Required) Path to the workflow folder (e.g., `./my-workflow`)

**Flags:**

| Flag               | Description                                                              |
| ------------------ | ------------------------------------------------------------------------ |
| `--all-registries` | Do not filter results by the workflow's configured `deployment-registry` |

**Examples:**

- Show metadata for the workflow configured for a target

  ```bash
  cre workflow get ./my-workflow --target staging-settings
  ```

- Search across all registries in your organization

  ```bash
  cre workflow get ./my-workflow --target staging-settings --all-registries
  ```

The command prints the same human-readable workflow metadata fields as [`cre workflow list`](#cre-workflow-list): workflow name, workflow ID, owner address, status, registry, and registry address when available.

***

## `cre workflow custom-build`

> **CAUTION: Irreversible operation**
>
> This command permanently modifies your `workflow.yaml`, updating `workflow-path` to `./wasm/workflow.wasm` across all targets. It cannot be undone. After conversion, the CLI will no longer compile your source code automatically — your `Makefile` is responsible for producing the WASM binary.

Converts a workflow to use a custom self-compiled WASM build. Instead of the CLI compiling your source automatically, a generated `Makefile` owns the build step. Use this when you need custom compiler flags, CI/CD artifact promotion, pre-build validation, or non-standard toolchains.

**Usage:**

```bash
cre workflow custom-build <workflow-folder-path> [flags]
```

**Arguments:**

- `<workflow-folder-path>` — (Required) Path to the workflow folder (e.g., `./my-workflow`)

**Flags:**

| Flag          | Description                                      |
| ------------- | ------------------------------------------------ |
| `-f, --force` | Skip confirmation prompt and convert immediately |

**Example:**

```bash
cre workflow custom-build ./my-workflow
```

**Expected output:**

```bash
✓ Workflow converted to custom build. workflow-path is now ./wasm/workflow.wasm
  The Makefile is configured to output the WASM to this path. Run: make build
```

For a full guide including Makefile examples and customization, see [Custom WASM Builds](/cre/guides/operations/custom-build).

***

## `cre workflow hash`

Computes and displays content hashes for a workflow without deploying it. Reports the binary hash, config hash, and the workflow hash — the same value used as the onchain workflow ID. This is useful for verifying what will be deployed before submitting a transaction, or for confirming that a build artifact is identical to a previously deployed version.

Hashes are also displayed automatically during `cre workflow build` and `cre workflow deploy`.

**Usage:**

```bash
cre workflow hash <workflow-folder-path> [flags]
```

**Arguments:**

- `<workflow-folder-path>` — (Required) Path to the workflow folder (e.g., `./my-workflow`)

**Flags:**

| Flag                 | Description                                                                                                                                                          |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--public_key`       | Owner address to use when computing the workflow hash. Required when `CRE_ETH_PRIVATE_KEY` is not set and no `workflow-owner-address` is configured in your settings |
| `--wasm`             | Path or URL to a pre-built WASM binary (skips compilation)                                                                                                           |
| `--config`           | Override the config file path from `workflow.yaml`                                                                                                                   |
| `--no-config`        | Compute hash without a config file                                                                                                                                   |
| `--skip-type-checks` | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds                                          |

> **NOTE: Owner address required**
>
> This command needs your owner address to compute the workflow hash, since the hash incorporates the owner. It derives this from `CRE_ETH_PRIVATE_KEY` by default. If you don't want to provide a private key, pass your address directly with `--public_key`.

**Examples:**

- Compute hashes using settings from `workflow.yaml`

  ```bash
  cre workflow hash my-workflow --target staging-settings
  ```

- Compute hashes without providing a private key

  ```bash
  cre workflow hash my-workflow --public_key 0xYourOwnerAddress --target staging-settings
  ```

- Compute hashes for a pre-built binary without recompiling

  ```bash
  cre workflow hash my-workflow --wasm ./my-workflow/binary.wasm --target staging-settings
  ```

**Example output:**

```
✓ Workflow compiled
  Binary hash:   0dcbb19de3c22edfe61605a970eb6d42199df91ac3e992cd3f2e33cb13efbb4c
  Config hash:   3bdaebcc2f639d77cb248242c1d01c8651f540cdbf423d26fe3128516fd225b6
  Workflow hash: 004fff5bb1ae05cc16e453f8ad564f5e8b0eae1945ec22f3d0adfc0339954d56
```

> **NOTE: Workflow hash = Workflow ID**
>
> The **workflow hash** is the same value that appears as the **Workflow ID** onchain. If your consumer contracts validate the workflow ID, use `cre workflow hash` to check the expected ID before and after updates. See [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows) for details.

## `cre workflow limits`

Manage simulation limits. Use this command to inspect the default production limits used during `cre workflow simulate`.

### `cre workflow limits export`

Prints the default production limits as JSON to stdout. Use this as a starting point for creating a custom limits file.

**Usage:**

```bash
cre workflow limits export
```

**Example:**

```bash
cre workflow limits export > my-limits.json
```

Redirect the output to a file, edit the values you want to adjust, then pass the file to `cre workflow simulate` with the `--limits` flag:

```bash
cre workflow simulate ./my-workflow --limits ./my-limits.json --target staging-settings
```

See [Testing Production Limits](/cre/guides/operations/understanding-limits) for a full walkthrough.

***

## Workflow lifecycle

The typical workflow lifecycle uses these commands in sequence:

1. **Develop locally** — Write and iterate on your workflow code
2. **`cre workflow limits export`** — (Optional) Inspect and customize production limits before simulating
3. **`cre workflow simulate`** — Test your workflow in a local simulation environment
4. **`cre workflow build`** — (Optional) Compile to WASM independently; useful in CI/CD pipelines
5. **`cre workflow hash`** — (Optional) Inspect content hashes before deploying
6. **`cre workflow deploy`** — Deploy your workflow to the registry
7. **`cre workflow pause`** / **`cre workflow activate`** — Control workflow execution as needed
8. **`cre workflow deploy`** (again) — Deploy updates (replaces the existing workflow)
9. **`cre workflow list`** — (Optional) View all deployed workflows for your organization
10. **`cre workflow get`** — (Optional) Inspect metadata for the workflow configured in `workflow.yaml`
11. **`cre workflow delete`** — Remove the workflow when no longer needed

## Learn more

- [Testing Production Limits](/cre/guides/operations/understanding-limits) — Using the `--limits` flag and `cre workflow limits export`
- [Simulating Workflows](/cre/guides/operations/simulating-workflows) — Detailed simulation guide
- [Deploying Workflows](/cre/guides/operations/deploying-workflows) — Detailed deployment guide, including CI/CD pipeline integration
- [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows) — Managing workflow state
- [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows) — Version management
- [Deleting Workflows](/cre/guides/operations/deleting-workflows) — Cleanup and removal