Deploying Workflows

When you deploy a workflow, you take your locally tested code and register it with a workflow registry so it can activate and respond to triggers across a Decentralized Oracle Network (DON). CRE supports two registry models today:

• Public workflow: Workflow management goes through the onchain Workflow Registry contract on Ethereum Mainnet. Use deployment-registry: "onchain:ethereum-mainnet".
• Private workflow: Workflow management goes through the Chainlink-hosted private registry. Use deployment-registry: "private".

This is a control-plane choice for workflow management: deploy, update, activate, pause, delete, and related ownership. It is not an execution-privacy setting.

Prerequisites

Before you can deploy a workflow, you must have:

• Early Access approval: Workflow deployment is currently in Early Access. Run cre account access to check your status or submit a request. See Requesting Deploy Access.
• Authenticated: Logged in via cre login or using an API key (CRE_API_KEY). To verify, run cre whoami.
• A deployment-registry value in workflow.yaml: Updated CLI-generated targets include deployment-registry: "private" by default. For older workflow files, make sure the target has a registry ID from cre registry list.
• (Onchain registry only) Linked your key: Required only when the target's deployment-registry is set to onchain:ethereum-mainnet. Link your EOA or multi-sig wallet to your account by running cre account link-key. Workflows deployed to the private registry do not need a linked key.
• (Onchain registry only) A funded wallet: The deploying account must hold ETH on Ethereum Mainnet to pay gas for the registration transaction. Not required for the private registry.

Choosing your registry

Each target deploys to exactly one registry, selected by the user-workflow.deployment-registry field in workflow.yaml. Run cre registry list to see which registries are available to your organization:

cre registry list

Example output:

Registries available to your organization

ethereum-mainnet (0x4Ac5...E7e5)
  ID:   onchain:ethereum-mainnet
  Type: onchain
  Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5

Private (Chainlink-hosted)
  ID:   private
  Type: offchain

Use the ID value as the value of deployment-registry in your workflow.yaml.

Private vs. public workflow management

CRE exposes two ways to manage the lifecycle of a workflow (deploy, activate, pause, update, delete) and its secrets — together, this is the control plane. Pick per target by setting deployment-registry:

Use the private registry when you want centralized, offchain workflow management, especially for lower-friction testing and team-managed workflows. Use the public onchain registry when workflow lifecycle operations must be recorded on the public Workflow Registry contract.

Secrets follow the same authorization split. See Managing with a web3 key and Managing with auth only below for the per-flow specifics, and Using Secrets with Deployed Workflows for the secrets equivalent.

Managing with a web3 key

Use this flow when deployment-registry: "onchain:ethereum-mainnet":

1. Link your EOA or multi-sig wallet to your organization with cre account link-key. See Linking Wallet Keys.
2. Set CRE_ETH_PRIVATE_KEY in your .env and add an RPC URL for ethereum-mainnet to your project.yaml.
3. Run cre workflow deploy (or activate, pause, delete, update). Each command builds a transaction, prompts you to confirm, and submits it onchain. The Workflow Registry emits an event tying the workflow ID to your wallet address — that address is the workflow's owner and is what you'll see on the CRE platform UI.
4. For multi-sig wallets, pass --unsigned to print the raw transaction data instead of broadcasting. See Using Multi-sig Wallets.

Managing with auth only

Use this flow when deployment-registry: "private":

1. Log in once with cre login.
2. Run cre workflow deploy (or activate, pause, delete, update). The CLI authorizes the operation against the Chainlink-hosted registry using your CRE login session. No .env private key, no wallet linking, and no Ethereum Mainnet RPC are required for these commands.
3. Workflows show as private in the CRE platform UI. The Owner is your CRE organization rather than a wallet address.

If a target needs to deploy to the onchain registry but you have no CRE_ETH_PRIVATE_KEY configured, the CLI errors out before submitting anything (e.g., failed to load settings: failed to parse private key. Please check CRE_ETH_PRIVATE_KEY in your .env file or system environment).

Migrate an existing workflow

CRE CLI v2.0.0 defaults new workflow targets to the private registry. Existing deployed workflows continue to run, but older workflow.yaml files may not have deployment-registry yet. If a redeploy, recompile, or workflow-management command reports the missing field, update the affected target before rerunning the command.

Who is affected

You need to migrate if your workflow target has a user-workflow section without deployment-registry:

staging-settings:
  user-workflow:
    workflow-name: "my-workflow-staging"
  workflow-artifacts:
    workflow-path: "./main.ts"
    config-path: "./config.staging.json"

After upgrading, the CLI reports the missing field and points to the target that needs the update:

Error: "deployment-registry" is required in target "staging-settings" as of CRE CLI v2.0.0.

Add the field to your workflow.yaml under each target's user-workflow section:

  staging-settings:
    user-workflow:
      deployment-registry: "private"

Run "cre registry list" to see your available registries.

Use private for Chainlink-hosted private registry management. If your existing workflow was already managed through the public onchain registry, use onchain:ethereum-mainnet instead so the workflow stays on the same registry.

Step 1: List available registries

Log in, then list the registries available to your organization:

cre login
cre registry list

Use the ID value from the output in workflow.yaml.

Step 2: Choose public or private workflow management

Choose the registry that matches how you want to manage the workflow:

• Choose onchain:ethereum-mainnet to keep an existing public/onchain workflow on the same public registry. This keeps the linked-key and gas-based management path.
• Choose private for private, centralized, offchain workflow management. This removes linked-key, Ethereum Mainnet RPC, and gas requirements for workflow registry operations.

The private registry only changes workflow management. It does not make execution confidential, and it does not replace any gas or funding requirements that apply to onchain actions performed by the workflow itself.

Step 3: Update affected targets

Add deployment-registry under user-workflow for each target that is missing it.

Keep an existing workflow on the public onchain registry:

staging-settings:
  user-workflow:
    workflow-name: "my-workflow-staging"
    deployment-registry: "onchain:ethereum-mainnet"
  workflow-artifacts:
    workflow-path: "./main.ts"
    config-path: "./config.staging.json"

Use the private registry for workflow management:

staging-settings:
  user-workflow:
    workflow-name: "my-workflow-staging"
    deployment-registry: "private"
  workflow-artifacts:
    workflow-path: "./main.ts"
    config-path: "./config.staging.json"

Repeat this for production-settings and any other target that needs migration.

Step 4: Re-run the command

After the YAML is updated, rerun the command that failed:

cre workflow deploy my-workflow --target staging-settings

If you chose onchain:ethereum-mainnet, keep your linked wallet key, CRE_ETH_PRIVATE_KEY, Ethereum Mainnet RPC, and funded wallet configuration. If you chose private, workflow deployment and lifecycle management use your CRE login session instead.

The deployment process

The cre workflow deploy command handles the entire end-to-end process for you:

1. Compiles your workflow to a WASM binary.
2. Uploads the compiled binary and any associated configuration files (like your config file or secrets.yaml) to the CRE Storage Service.
3. Registers the workflow with the registry selected by user-workflow.deployment-registry:
   • onchain:ethereum-mainnet — submits a transaction to the Workflow Registry contract on Ethereum Mainnet. Your wallet must have ETH for gas fees, and your project.yaml must include an RPC configuration for ethereum-mainnet (e.g., https://ethereum-rpc.publicnode.com). The transaction contains the workflow's name, owner, and artifact URLs.
   • private — registers the workflow with the Chainlink-hosted private registry, authorized by your CRE login session. No transaction, gas, or Ethereum Mainnet RPC is required for registry management.

Step 1: Ensure your configuration is correct

Before deploying, ensure your workflow.yaml file is correctly configured. The workflow-name and deployment-registry fields are required under the user-workflow section for your target environment.

If you are deploying to the onchain registry from a multi-sig wallet, specify your multi-sig address in the workflow-owner-address field. If you are deploying to the onchain registry from a standard EOA, you can leave this field unchanged—the owner will be automatically derived from the CRE_ETH_PRIVATE_KEY in your .env file. Private registry deployments use your CRE login session for workflow management and do not require workflow-owner-address.

For more details on configuration, see the Project Configuration reference.

Step 2: Run the deploy command

From your project root directory, run the deploy command with the path to your workflow folder.

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

Example command to target the production-settings environment:

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

Available flags:

Step 3: Monitor the output

The CLI will provide detailed logs of the deployment process, including compilation, upload to the CRE Storage Service, and the registry operation. Public onchain deployments include transaction details; private registry deployments do not submit an Ethereum Mainnet transaction.

Example onchain registry output:

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

Deploying Workflow :     my-workflow
Target :                 production-settings
Owner Address :          <your-owner-address>

Compiling workflow...
Workflow compiled successfully

Verifying ownership...
Workflow owner link status: owner=<your-owner-address>, linked=true
Key ownership verified

Uploading files...
✔ Loaded binary from: ./binary.wasm.br.b64
✔ Uploaded binary to: https://storage.cre.example.com/artifacts/<workflow-id>/binary.wasm
✔ Loaded config from: ./config.json
✔ Uploaded config to: https://storage.cre.example.com/artifacts/<workflow-id>/config

Preparing deployment transaction...
Preparing transaction for workflowID: <your-workflow-id>
Transaction details:
  Chain Name:   ethereum-mainnet
  To:           0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5
  Function:     UpsertWorkflow
  Inputs:
    [0]:        my-workflow
    [1]:        my-workflow
    [2]:        <your-workflow-id>
    [3]:        0
    [4]:        zone-a
    [5]:        https://storage.cre.example.com/artifacts/<workflow-id>/binary.wasm
    [6]:        https://storage.cre.example.com/artifacts/<workflow-id>/config
    [7]:        0x
    [8]:        false
  Data:         b377bfc50000000000000000000000000000000000...
Estimated Cost:
  Gas Price:      0.00100001 gwei
  Total Cost:     0.00000079 ETH
? Do you want to execute this transaction?:
  ▸ Yes
    No

Transaction confirmed
View on explorer: https://etherscan.io/tx/0x58599f6...d916b

✓ Workflow deployed successfully

Details:
   Registry:         onchain:ethereum-mainnet
   Contract address: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5
   Transaction hash: 0x58599f6...d916b
   Workflow Name:    my-workflow
   Workflow ID:      <your-workflow-id>
   Binary URL:       https://storage.cre.example.com/artifacts/<workflow-id>/binary.wasm
   Config URL:       https://storage.cre.example.com/artifacts/<workflow-id>/config

Example private/offchain registry output:

> cre workflow deploy my-workflow --target staging-settings

Deploying Workflow :     my-workflow
Target :                 staging-settings
Owner Address :          <your-organization-owner>

Compiling workflow...
Workflow compiled successfully

Uploading files...
✔ Loaded binary from: ./binary.wasm.br.b64
✔ Uploaded binary to: https://storage.cre.example.com/artifacts/<workflow-id>/binary.wasm
✔ Loaded config from: ./config.json
✔ Uploaded config to: https://storage.cre.example.com/artifacts/<workflow-id>/config

Registering workflow in private registry (workflowID: <your-workflow-id>)...
✓ Workflow registered in private registry

Details:
   Registry:         private
   Workflow Name:    my-workflow
   Workflow ID:      <your-workflow-id>
   Status:           Active
   Binary URL:       https://storage.cre.example.com/artifacts/<workflow-id>/binary.wasm
   Config URL:       https://storage.cre.example.com/artifacts/<workflow-id>/config
   Owner:            <your-organization-owner>

Verifying your deployment

After a successful deployment, you can verify that your workflow was registered correctly:

1. CLI: Run cre workflow list to see every workflow registered to your organization, the registry each was deployed to, and its current status. Workflows on the private registry are tagged private in the output.

2. CRE UI: View your deployed workflow in the CRE platform. Navigate to the Workflows section to see your workflow's status, ID, and execution history. Workflows deployed to the private registry are also tagged private in the UI.

3. Block Explorer (onchain registry only): For workflows deployed with deployment-registry: "onchain:ethereum-mainnet", the CLI output includes the transaction hash for the registration. The WorkflowRegistry contract is deployed on Ethereum Mainnet at 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5.

CI/CD pipeline integration

The cre workflow build and cre workflow deploy commands can be run as independent steps, making it straightforward to integrate CRE deployments into CI/CD pipelines.

The separation gives you two key benefits:

• Build once, deploy many times — Compile your workflow to a WASM binary in a build step, then promote that exact binary to staging and production without recompiling. This ensures the artifact you tested is the artifact you deploy.
• Verify before deploying — Use cre workflow hash after building to record and verify content hashes before submitting a deployment transaction.

Example: GitHub Actions

The following example shows a two-job pipeline: a build job that compiles and uploads the WASM artifact, and a deploy job that downloads and deploys that exact binary.

# .github/workflows/deploy.yml
name: Deploy Workflow

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install CRE CLI
        run: curl -sSL https://github.com/smartcontractkit/cre-cli/releases/latest/download/install.sh | sh

      - name: Build workflow
        run: cre workflow build ./my-workflow --output ./my-workflow/binary.wasm --non-interactive
        env:
          CRE_API_KEY: ${{ secrets.CRE_API_KEY }}

      - name: Display content hashes
        run: cre workflow hash ./my-workflow --wasm ./my-workflow/binary.wasm --target production-settings --non-interactive
        env:
          CRE_API_KEY: ${{ secrets.CRE_API_KEY }}
          CRE_ETH_PRIVATE_KEY: ${{ secrets.CRE_ETH_PRIVATE_KEY }}

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: workflow-binary
          path: ./my-workflow/binary.wasm

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install CRE CLI
        run: curl -sSL https://github.com/smartcontractkit/cre-cli/releases/latest/download/install.sh | sh

      - name: Download artifact
        uses: actions/download-artifact@v4
        with:
          name: workflow-binary
          path: ./my-workflow

      - name: Deploy workflow
        run: cre workflow deploy ./my-workflow --wasm ./my-workflow/binary.wasm --target production-settings --yes --non-interactive
        env:
          CRE_API_KEY: ${{ secrets.CRE_API_KEY }}
          CRE_ETH_PRIVATE_KEY: ${{ secrets.CRE_ETH_PRIVATE_KEY }}
          INFURA_API_KEY: ${{ secrets.INFURA_API_KEY }}

Using multi-sig wallets

The deploy command supports multi-sig wallets through the --unsigned flag. When using this flag, the CLI generates raw transaction data that you can submit through your multi-sig wallet interface instead of sending the transaction directly.

For complete setup instructions, configuration requirements, and step-by-step guidance, see Using Multi-sig Wallets.

Next steps

• Activating & Pausing Workflows: Learn how to control workflow execution
• Monitoring Workflows: Track your workflow's execution and performance
• Updating Deployed Workflows: Deploy new versions of your workflow