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
  

cre workflow deploy

Deploys a workflow to the Workflow Registry contract. This command compiles your workflow, uploads the artifacts to the CRE Storage Service, and registers the workflow onchain.

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 on the Workflow Registry contract. 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 on the Workflow Registry contract. 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 Workflow 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 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

Workflow lifecycle

The typical workflow lifecycle uses these commands in sequence:

1. Develop locally — Write and iterate on your workflow code
2. cre workflow simulate — Test your workflow in a local simulation environment
3. cre workflow build — (Optional) Compile to WASM independently; useful in CI/CD pipelines
4. cre workflow hash — (Optional) Inspect content hashes before deploying
5. cre workflow deploy — Deploy your workflow to the registry
6. cre workflow pause / cre workflow activate — Control workflow execution as needed
7. cre workflow deploy (again) — Deploy updates (replaces the existing workflow)
8. cre workflow delete — Remove the workflow when no longer needed

Learn more

• 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