Workflow Commands

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

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:

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

Arguments:

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

Flags:

Example:

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.

For CI/CD usage, see Deploying Workflows.

cre workflow simulate

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:

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:

Examples:

• Basic simulation

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

• Broadcast real onchain transactions

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

• Non-interactive mode with HTTP trigger

  # 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

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

  cre workflow simulate ./my-workflow --listen --target local-simulation
  

• Listen mode — re-run on every matching EVM log event

  cre workflow simulate ./my-workflow --listen --trigger-index 1 --target staging-settings
  

cre workflow supported-chains

Lists the chains enabled for your tenant and their mock Keystone 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 before setting up a simulation target 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:

cre workflow supported-chains [flags]

Flags:

Examples:

cre workflow supported-chains
cre workflow supported-chains --output json

Example (default output, excerpt):

Chains and mock forwarders (tenant-scoped):

CHAIN                              SELECTOR              MOCK FORWARDER
ethereum-mainnet-arbitrum-1        4949039107694359620   0xF8344CFd5c43616a4366C34E3EEE75af79a74482
ethereum-mainnet                   5009297550715157269   0x0b93082D9b3C7C97fAcd250082899BAcf3af3885
ethereum-testnet-sepolia           16015286601757825753  0xF8344CFd5c43616a4366C34E3EEE75af79a74482
polygon-mainnet                    4051577828743386545   0x76c9cf548b4179F8901cda1f8623568b58215E62
...

Example (JSON output, excerpt):

[
  {
    "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 mock and production forwarder addresses by network, see the Forwarder Directory.

cre workflow deploy

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 to see which registries your organization can use.

Usage:

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:

Examples:

• Deploy workflow

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

• Deploy and save the compiled binary to a custom location

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

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

  # 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
  

For more details, see Deploying Workflows.

cre workflow activate

Changes the workflow status to active in the registry selected by deployment-registry. Active workflows can respond to their configured triggers.

Usage:

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:

Example:

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

For more details, see Activating & Pausing Workflows.

cre workflow pause

Changes the workflow status to paused in the registry selected by deployment-registry. Paused workflows will not respond to triggers.

Usage:

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:

Example:

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

For more details, see Activating & Pausing Workflows.

cre workflow delete

Deletes a workflow from the registry selected by deployment-registry.

Usage:

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:

Example:

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

For more details, see Deleting Workflows.

cre workflow list

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

Usage:

cre workflow list [flags]

Flags:

Examples:

• List all workflows

  cre workflow list
  

• List all workflows including deleted ones

  cre workflow list --include-deleted
  

• Export workflow list as JSON

  cre workflow list --output json > workflows.json
  

JSON output fields:

Example JSON output:

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

cre workflow get

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:

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

Arguments:

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

Flags:

Examples:

• Show deployment health and recent execution for the workflow configured for a target

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

• Resolve across all registries in your organization

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

• Export as JSON

  cre workflow get ./my-workflow --target staging-settings --output json
  

For a full execution history, use cre execution list.

cre workflow custom-build

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:

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

Arguments:

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

Flags:

Example:

cre workflow custom-build ./my-workflow

Expected output:

✓ 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 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:

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

Arguments:

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

Flags:

Examples:

• Compute hashes using settings from workflow.yaml

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

• Compute hashes without providing a private key

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

• Compute hashes for a pre-built binary without recompiling

  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

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:

cre workflow limits export

Example:

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:

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

See Testing Production 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 — Using the --limits flag and cre workflow limits export
• Simulating Workflows — Detailed simulation guide
• Deploying Workflows — Detailed deployment guide, including CI/CD pipeline integration
• Activating & Pausing Workflows — Managing workflow state
• Updating Deployed Workflows — Version management
• Deleting Workflows — Cleanup and removal