# 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 registry selected by `user-workflow.deployment-registry` in `workflow.yaml`. This command compiles your workflow, uploads the artifacts to the CRE Storage Service, and registers the workflow with either the public onchain Workflow Registry or the Chainlink-hosted private registry. Use [`cre registry list`](/cre/reference/cli/registry) to see which registries your organization can 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`         | Onchain registry only: 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 in the registry selected by `deployment-registry`. 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` | Onchain registry only: 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 in the registry selected by `deployment-registry`. 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` | Onchain registry only: 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 registry selected by `deployment-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` | Onchain registry only: 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