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 registries today: the on-chain Workflow Registry contract on Ethereum Mainnet and the private Chainlink-hosted registry. Pick which one a target deploys to with the deployment-registry field in your workflow.yaml.

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.
  • (On-chain 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 default private registry do not need a linked key.
  • (On-chain 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: on-chain
  Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5

Private (Chainlink-hosted)
  ID:   private
  Type: off-chain

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

Control plane: web3 key vs. auth-only

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:

  • On-chain registry (onchain:ethereum-mainnet) — managed with a web3 key. Each lifecycle command submits a transaction to the on-chain Workflow Registry contract, signed by your linked wallet. Requires cre account link-key, an RPC for Ethereum Mainnet, and a funded wallet to pay gas.
  • Private registry (private) — managed with auth only. Each lifecycle command is authorized by your CRE login session (cre login). No wallet, no gas, no key linking. Multiple team members on the same organization can manage the same workflows once authenticated.

Secrets follow the same 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" (the default):

  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 on-chain 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).

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 (default) — registers the workflow with the Chainlink-hosted registry, authorized by your CRE login session. No transaction, gas, or RPC is required.

Step 1: Ensure your configuration is correct

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

If you are deploying from a multi-sig wallet, specify your multi-sig address in the workflow-owner-address field. If you are deploying 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.

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:

FlagDescription
--targetSets the target environment from your configuration files (e.g., production-settings)
--outputThe output file for the compiled WASM binary (default: "./binary.wasm.br.b64")
--wasmPath to a pre-built WASM binary (skips compilation). Useful in CI/CD pipelines
--configOverride the config file path from workflow.yaml
--no-configDeploy without a config file
--unsignedReturn the raw transaction instead of broadcasting it to the network
--yesSkip confirmation prompts and proceed with the operation
--project-rootPath to the project root directory
--envPath to your .env file (default: ".env")
--verboseEnable verbose logging to print DEBUG level logs

Step 3: Monitor the output

The CLI will provide detailed logs of the deployment process, including the compilation, upload to the CRE Storage Service, and the final onchain transaction.

> 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

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 (on-chain 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
        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
        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
        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

Get the latest Chainlink content straight to your inbox.