# Workflow Commands Source: https://docs.chain.link/cre/reference/cli/workflow Last Updated: 2026-07-09 > 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 [flags] ``` **Arguments:** - `` — (Required) Path to the workflow folder (e.g., `./my-workflow`) **Flags:** | Flag | Description | | -------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `-o, --output` | Output file path for the compiled WASM binary (default: `/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 [flags] ``` **Arguments:** - `` — (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 | | `--listen` | Keep the simulator alive and re-run it for each incoming trigger event. For HTTP triggers, listens for POST requests on port `2000`. For EVM log triggers, watches the chain and re-runs on each matching event. Useful when iterating on trigger-driven workflows without restarting the simulator between runs | | `--non-interactive` | Run without prompts; requires `--trigger-index` (see the line below) and inputs for the selected trigger type | | `--trigger-index ` | 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 ` | 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 ` | Transaction hash (`0x...`) containing the event that triggered your workflow. For EVM log triggers only | | `--evm-event-index ` | 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 | | `--evm-receipt-timeout ` | How long to wait for an EVM transaction receipt before timing out (e.g. `30s`, `2m`). For EVM log triggers only (default: `1m`) | | `--limits ` | 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 ``` - Listen mode — re-run on every HTTP trigger POST (port 2000) ```bash cre workflow simulate ./my-workflow --listen --target local-simulation ``` - Listen mode — re-run on every matching EVM log event ```bash cre workflow simulate ./my-workflow --listen --trigger-index 1 --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. > **TIP: Which chains can I simulate?** > > Run [`cre workflow supported-chains`](/cre/reference/cli/workflow#cre-workflow-supported-chains) to list the chains and forwarder addresses enabled for your tenant. Authentication is required — run `cre login` first. ## `cre workflow supported-chains` > **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 the chains enabled for your tenant and their forwarder addresses. Chains are returned from the platform based on your login session (`cre login` or `CRE_API_KEY`). Non-EVM chains configured for your tenant also appear in the output. Use this command to confirm chain availability and copy the forwarder address for use in consumer contracts. If no authenticated context is found, the CLI will prompt you to run `cre login`. **Usage:** ```bash cre workflow supported-chains [flags] ``` **Flags:** | Flag | Description | | ------------------- | -------------------------------------------------------------------------------------- | | `--output ` | Output format. Use `json` to print a JSON array to stdout for scripting and automation | **Examples:** ```bash cre workflow supported-chains cre workflow supported-chains --output json ``` **Example (default output, excerpt):** ```text Chains and forwarders (tenant-scoped): CHAIN SELECTOR FORWARDER ethereum-mainnet-arbitrum-1 4949039107694359620 0xF8344CFd5c43616a4366C34E3EEE75af79a74482 ethereum-mainnet 5009297550715157269 0x0b93082D9b3C7C97fAcd250082899BAcf3af3885 ethereum-testnet-sepolia 16015286601757825753 0xF8344CFd5c43616a4366C34E3EEE75af79a74482 polygon-mainnet 4051577828743386545 0x76c9cf548b4179F8901cda1f8623568b58215E62 ... ``` **Example (JSON output, excerpt):** ```json [ { "chainName": "ethereum-mainnet-arbitrum-1", "chainSelector": 4949039107694359620, "address": "0xF8344CFd5c43616a4366C34E3EEE75af79a74482" }, { "chainName": "ethereum-mainnet", "chainSelector": 5009297550715157269, "address": "0x0b93082D9b3C7C97fAcd250082899BAcf3af3885" }, { "chainName": "ethereum-testnet-sepolia", "chainSelector": 16015286601757825753, "address": "0xF8344CFd5c43616a4366C34E3EEE75af79a74482" } ] ``` The chain list is tenant-specific and may vary between organizations. Run the command locally for the full set of chains and forwarder addresses enabled for your account. For a full reference of forwarder addresses by network, see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory). ## `cre workflow deploy` > **NOTE: Deployment access required** > > Deploying workflows requires 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 [flags] ``` **Arguments:** - `` — (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 [flags] ``` **Arguments:** - `` — (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 [flags] ``` **Arguments:** - `` — (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 [flags] ``` **Arguments:** - `` — (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 ` | Output format. Use `json` to print a JSON array to stdout for scripting use cases | | `--registry ` | 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 deployment health and the most recent execution for the workflow configured in `workflow.yaml`. The command reads the workflow name for the selected `--target`, resolves the workflow on the CRE platform (scoped to the configured `deployment-registry` by default), and prints deployment health plus the latest execution. **Usage:** ```bash cre workflow get [flags] ``` **Arguments:** - `` — (Required) Path to the workflow folder (e.g., `./my-workflow`) **Flags:** | Flag | Description | | ------------------- | ------------------------------------------------------------------------------------------ | | `--all-registries` | Resolve the workflow across every registry instead of the configured `deployment-registry` | | `--output ` | Output format. Use `json` to print JSON to stdout for scripting | | `--json` | Shorthand for `--output=json` | **Examples:** - Show deployment health and recent execution for the workflow configured for a target ```bash cre workflow get ./my-workflow --target staging-settings ``` - Resolve across all registries in your organization ```bash cre workflow get ./my-workflow --target staging-settings --all-registries ``` - Export as JSON ```bash cre workflow get ./my-workflow --target staging-settings --output json ``` For a full execution history, use [`cre execution list`](/cre/reference/cli/execution#cre-execution-list). *** ## `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 [flags] ``` **Arguments:** - `` — (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 [flags] ``` **Arguments:** - `` — (Required) Path to the workflow folder (e.g., `./my-workflow`) **Flags:** | Flag | Description | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--public_key` | Owner address to use when computing the workflow hash. The command auto-derives the owner based on your registry type: on-chain uses `workflow-owner-address` or `CRE_ETH_PRIVATE_KEY`; off-chain uses the owner from your login session. Pass `--public_key` to override the auto-derived address | | `--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** > > The workflow hash incorporates the owner address. The command auto-derives this based on your registry: **on-chain** uses `workflow-owner-address` from settings or `CRE_ETH_PRIVATE_KEY`; **off-chain** uses the owner from your `cre login` session or `CRE_API_KEY`. Use `--public_key` to override the auto-derived address. **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