From b3513d482b081fd55513351f1a2700d5c5001acf Mon Sep 17 00:00:00 2001 From: De Clercq Wentzel <10665586+wentzeld@users.noreply.github.com> Date: Tue, 28 Apr 2026 17:01:02 -0700 Subject: [PATCH 1/9] docs(cre): document private registry, control plane, and deployment-registry breaking change --- .../getting-started/before-you-build-go.mdx | 4 +- .../getting-started/before-you-build-ts.mdx | 4 +- .../part-1-project-setup-go.mdx | 2 +- .../part-1-project-setup-ts.mdx | 2 +- .../guides/operations/deploying-workflows.mdx | 85 ++++++- .../secrets/using-secrets-deployed.mdx | 19 +- src/content/cre/key-terms.mdx | 9 + src/content/cre/llms-full-go.txt | 211 +++++++++++++++--- src/content/cre/llms-full-ts.txt | 211 +++++++++++++++--- src/content/cre/reference/cli/registry.mdx | 6 + src/content/cre/reference/cli/secrets.mdx | 47 ++-- .../reference/project-configuration-go.mdx | 25 ++- .../reference/project-configuration-ts.mdx | 25 ++- src/content/cre/release-notes.mdx | 15 ++ 14 files changed, 550 insertions(+), 115 deletions(-) diff --git a/src/content/cre/getting-started/before-you-build-go.mdx b/src/content/cre/getting-started/before-you-build-go.mdx index 1ae8628f26e..300283bd2a3 100644 --- a/src/content/cre/getting-started/before-you-build-go.mdx +++ b/src/content/cre/getting-started/before-you-build-go.mdx @@ -56,8 +56,8 @@ Here are resources to help you go from simulation to production. Deploying requires Early Access approval. Run `cre account access` or visit app.chain.link/cre/request-access to submit a request. See [Requesting Deploy Access](/cre/account/deploy-access). While you wait, continue building and simulating workflows. -1. **[Link a Wallet Key](/cre/organization/linking-keys)** — Connect your wallet to your organization -1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live +1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. By default, deployments go to the Chainlink-hosted private registry using your CRE login — no wallet required. +1. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry. 1. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers diff --git a/src/content/cre/getting-started/before-you-build-ts.mdx b/src/content/cre/getting-started/before-you-build-ts.mdx index bad30a330e6..01cf2e63c90 100644 --- a/src/content/cre/getting-started/before-you-build-ts.mdx +++ b/src/content/cre/getting-started/before-you-build-ts.mdx @@ -122,8 +122,8 @@ Here are resources to help you go from simulation to production. Deploying requires Early Access approval. Run `cre account access` or visit app.chain.link/cre/request-access to submit a request. See [Requesting Deploy Access](/cre/account/deploy-access). While you wait, continue building and simulating workflows. -1. **[Link a Wallet Key](/cre/organization/linking-keys)** — Connect your wallet to your organization -1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live +1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. By default, deployments go to the Chainlink-hosted private registry using your CRE login — no wallet required. +1. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry. 1. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers diff --git a/src/content/cre/getting-started/part-1-project-setup-go.mdx b/src/content/cre/getting-started/part-1-project-setup-go.mdx index 87452c132af..0e0bfc78622 100644 --- a/src/content/cre/getting-started/part-1-project-setup-go.mdx +++ b/src/content/cre/getting-started/part-1-project-setup-go.mdx @@ -34,7 +34,7 @@ Before you begin, ensure you have the following: - **CRE CLI**: See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) for details. - **CRE account & authentication**: You must have a CRE account and be logged in with the CLI. See [Create your account](/cre/account/creating-account) and [Log in with the CLI](/cre/account/cli-login) for instructions. - **Go**: You must have Go version 1.25.3 or higher installed. Check your version with . See [Install Go](https://go.dev/doc/install) for instructions. -- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Go to faucets.chain.link to get some Sepolia ETH. +- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the default `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication diff --git a/src/content/cre/getting-started/part-1-project-setup-ts.mdx b/src/content/cre/getting-started/part-1-project-setup-ts.mdx index 74837dc30fb..fdb7e6e3546 100644 --- a/src/content/cre/getting-started/part-1-project-setup-ts.mdx +++ b/src/content/cre/getting-started/part-1-project-setup-ts.mdx @@ -34,7 +34,7 @@ Before you begin, ensure you have the following: - **CRE CLI**: See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) for details. - **CRE account & authentication**: You must have a CRE account and be logged in with the CLI. See [Create your account](/cre/account/creating-account) and [Log in with the CLI](/cre/account/cli-login) for instructions. - **Bun**: You must have Bun version 1.2.21 or higher installed. Check your version with . See [Install Bun](https://bun.com) for instructions. -- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Go to faucets.chain.link to get some Sepolia ETH. +- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the default `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication diff --git a/src/content/cre/guides/operations/deploying-workflows.mdx b/src/content/cre/guides/operations/deploying-workflows.mdx index 576187cfe75..0691a43079a 100644 --- a/src/content/cre/guides/operations/deploying-workflows.mdx +++ b/src/content/cre/guides/operations/deploying-workflows.mdx @@ -18,7 +18,21 @@ import { Aside } from "@components" -When you deploy a workflow, you take your locally tested code and register it with the onchain Workflow Registry contract. This makes your workflow "live" so it can activate and respond to triggers across a [Decentralized Oracle Network (DON)](/cre/key-terms#decentralized-oracle-network-don). +{/* prettier-ignore */} + + +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/key-terms#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 @@ -26,8 +40,61 @@ 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](/cre/account/deploy-access). - **[Authenticated](/cre/reference/cli/authentication)**: Logged in via `cre login` or using an [API key](/cre/reference/cli/authentication#api-key-authentication) (`CRE_API_KEY`). To verify, run `cre whoami`. -- **[Linked your key](/cre/reference/cli/account#cre-account-link-key)**: Linked your EOA or multi-sig wallet to your account by running `cre account link-key`. -- **A funded wallet**: The account you are deploying from must be funded with ETH on Ethereum Mainnet to pay the gas fees for the onchain registration transaction to the Workflow Registry contract. +- **(On-chain registry only) [Linked your key](/cre/reference/cli/account#cre-account-link-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: + +```bash +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](#managing-with-a-web3-key) and [Managing with auth only](#managing-with-auth-only) below for the per-flow specifics, and [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) 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](/cre/organization/linking-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](/cre/guides/operations/using-multisig-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 @@ -35,7 +102,9 @@ The `cre workflow deploy` command handles the entire end-to-end process for you: 1. **Compiles** your workflow to a WASM binary. 1. **Uploads** the compiled binary and any associated configuration files (like your config file or `secrets.yaml`) to the CRE Storage Service. -1. **Registers** the workflow onchain by submitting 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`). This transaction contains the metadata for your workflow, including its name, owner, and the URL of its artifacts in the storage service. +1. **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. {/* prettier-ignore */} -When you deploy a workflow, you take your locally tested code and register it with the onchain Workflow Registry contract. This makes your workflow "live" so it can activate and respond to triggers across a [Decentralized Oracle Network (DON)](/cre/key-terms#decentralized-oracle-network-don). + + + +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/key-terms#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 @@ -5759,8 +5813,61 @@ 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](/cre/account/deploy-access). - **[Authenticated](/cre/reference/cli/authentication)**: Logged in via `cre login` or using an [API key](/cre/reference/cli/authentication#api-key-authentication) (`CRE_API_KEY`). To verify, run `cre whoami`. -- **[Linked your key](/cre/reference/cli/account#cre-account-link-key)**: Linked your EOA or multi-sig wallet to your account by running `cre account link-key`. -- **A funded wallet**: The account you are deploying from must be funded with ETH on Ethereum Mainnet to pay the gas fees for the onchain registration transaction to the Workflow Registry contract. +- **(On-chain registry only) [Linked your key](/cre/reference/cli/account#cre-account-link-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: + +```bash +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](#managing-with-a-web3-key) and [Managing with auth only](#managing-with-auth-only) below for the per-flow specifics, and [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) 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](/cre/organization/linking-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](/cre/guides/operations/using-multisig-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 @@ -5768,7 +5875,9 @@ 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 onchain by submitting 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`). This transaction contains the metadata for your workflow, including its name, owner, and the URL of its artifacts in the 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. -1. **[Link a Wallet Key](/cre/organization/linking-keys)** — Connect your wallet to your organization -2. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live +1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. By default, deployments go to the Chainlink-hosted private registry using your CRE login — no wallet required. +2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry. 3. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers @@ -10304,7 +10434,7 @@ Before you begin, ensure you have the following: - **CRE CLI**: See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) for details. - **CRE account & authentication**: You must have a CRE account and be logged in with the CLI. See [Create your account](/cre/account/creating-account) and [Log in with the CLI](/cre/account/cli-login) for instructions. - **Go**: You must have Go version 1.25.3 or higher installed. Check your version with go version. See [Install Go](https://go.dev/doc/install) for instructions. -- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Go to faucets.chain.link to get some Sepolia ETH. +- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the default `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -16316,11 +16446,20 @@ Variable values are resolved from environment variables at runtime. This works a `workflow.yaml` captures details **unique to one workflow instance**, like its name. + + ```yaml # workflow.yaml staging-settings: user-workflow: workflow-name: "my-por-workflow-staging" + deployment-registry: "private" # Default. Use "onchain:ethereum-mainnet" to deploy to the on-chain registry. workflow-artifacts: workflow-path: "." # Points to the workflow directory config-path: "./config.staging.json" @@ -16330,6 +16469,7 @@ production-settings: user-workflow: workflow-owner-address: "
" # Optional: For multi-sig wallets workflow-name: "my-por-workflow-production" + deployment-registry: "onchain:ethereum-mainnet" # Pin to the on-chain Workflow Registry on Ethereum Mainnet. workflow-artifacts: workflow-path: "." # Points to the workflow directory config-path: "./config.production.json" @@ -16338,13 +16478,14 @@ production-settings: #### Configuration fields -| Field | Required | Description | -| -------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `user-workflow.workflow-name` | Yes | The name of your workflow. This name is used to identify the workflow when deploying, activating, or managing it via CLI commands. Best practice: include environment suffix (e.g., `-staging`, `-production`). | -| `user-workflow.workflow-owner-address` | No | Multi-sig wallet address (if applicable). Overrides the value from `project.yaml` for this specific workflow. See the `project.yaml` configuration table above for details. | -| `workflow-artifacts.workflow-path` | Yes | Path to your workflow entry point. For Go: `"."` (current directory). For TypeScript: `"./main.ts"` (or your entry file name). | -| `workflow-artifacts.config-path` | Yes | Path to your workflow configuration JSON file (e.g., `"./config.staging.json"` or `"./config.production.json"`). | -| `workflow-artifacts.secrets-path` | No | Path to your secrets YAML file (e.g., `"../secrets.yaml"`). Use `""` (empty string) if not using secrets. See [Secrets Management](/cre/guides/workflow/secrets) for details. | +| Field | Required | Description | +| -------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `user-workflow.workflow-name` | Yes | The name of your workflow. This name is used to identify the workflow when deploying, activating, or managing it via CLI commands. Best practice: include environment suffix (e.g., `-staging`, `-production`). | +| `user-workflow.workflow-owner-address` | No | Multi-sig wallet address (if applicable). Overrides the value from `project.yaml` for this specific workflow. See the `project.yaml` configuration table above for details. | +| `user-workflow.deployment-registry` | No | Selects which registry receives this target's deployment. Defaults to `"private"` (Chainlink-hosted; managed with your CRE login, no wallet required). Set to `"onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry contract — this requires a [linked web3 key](/cre/organization/linking-keys) and a funded wallet. Run [`cre registry list`](/cre/reference/cli/registry) to see registries available. | +| `workflow-artifacts.workflow-path` | Yes | Path to your workflow entry point. For Go: `"."` (current directory). For TypeScript: `"./main.ts"` (or your entry file name). | +| `workflow-artifacts.config-path` | Yes | Path to your workflow configuration JSON file (e.g., `"./config.staging.json"` or `"./config.production.json"`). | +| `workflow-artifacts.secrets-path` | No | Path to your secrets YAML file (e.g., `"../secrets.yaml"`). Use `""` (empty string) if not using secrets. See [Secrets Management](/cre/guides/workflow/secrets) for details. | -When you deploy a workflow, you take your locally tested code and register it with the onchain Workflow Registry contract. This makes your workflow "live" so it can activate and respond to triggers across a [Decentralized Oracle Network (DON)](/cre/key-terms#decentralized-oracle-network-don). + + + +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/key-terms#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 @@ -4858,8 +4912,61 @@ 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](/cre/account/deploy-access). - **[Authenticated](/cre/reference/cli/authentication)**: Logged in via `cre login` or using an [API key](/cre/reference/cli/authentication#api-key-authentication) (`CRE_API_KEY`). To verify, run `cre whoami`. -- **[Linked your key](/cre/reference/cli/account#cre-account-link-key)**: Linked your EOA or multi-sig wallet to your account by running `cre account link-key`. -- **A funded wallet**: The account you are deploying from must be funded with ETH on Ethereum Mainnet to pay the gas fees for the onchain registration transaction to the Workflow Registry contract. +- **(On-chain registry only) [Linked your key](/cre/reference/cli/account#cre-account-link-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: + +```bash +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](#managing-with-a-web3-key) and [Managing with auth only](#managing-with-auth-only) below for the per-flow specifics, and [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) 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](/cre/organization/linking-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](/cre/guides/operations/using-multisig-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 @@ -4867,7 +4974,9 @@ 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 onchain by submitting 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`). This transaction contains the metadata for your workflow, including its name, owner, and the URL of its artifacts in the 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. -1. **[Link a Wallet Key](/cre/organization/linking-keys)** — Connect your wallet to your organization -2. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live +1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. By default, deployments go to the Chainlink-hosted private registry using your CRE login — no wallet required. +2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry. 3. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers @@ -10197,7 +10327,7 @@ Before you begin, ensure you have the following: - **CRE CLI**: See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) for details. - **CRE account & authentication**: You must have a CRE account and be logged in with the CLI. See [Create your account](/cre/account/creating-account) and [Log in with the CLI](/cre/account/cli-login) for instructions. - **Bun**: You must have Bun version 1.2.21 or higher installed. Check your version with bun --version. See [Install Bun](https://bun.com) for instructions. -- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Go to faucets.chain.link to get some Sepolia ETH. +- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the default `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -16174,11 +16304,20 @@ Variable values are resolved from environment variables at runtime. This works a `workflow.yaml` captures details **unique to one workflow instance**, like its name and entry point file. + + ```yaml # workflow.yaml staging-settings: user-workflow: workflow-name: "my-por-workflow-staging" + deployment-registry: "private" # Default. Use "onchain:ethereum-mainnet" to deploy to the on-chain registry. workflow-artifacts: workflow-path: "./main.ts" # Points to the TypeScript entry file config-path: "./config.staging.json" @@ -16188,6 +16327,7 @@ production-settings: user-workflow: workflow-owner-address: "
" # Optional: For multi-sig wallets workflow-name: "my-por-workflow-production" + deployment-registry: "onchain:ethereum-mainnet" # Pin to the on-chain Workflow Registry on Ethereum Mainnet. workflow-artifacts: workflow-path: "./main.ts" # Points to the TypeScript entry file config-path: "./config.production.json" @@ -16196,13 +16336,14 @@ production-settings: #### Configuration fields -| Field | Required | Description | -| -------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `user-workflow.workflow-name` | Yes | The name of your workflow. This name is used to identify the workflow when deploying, activating, or managing it via CLI commands. Best practice: include environment suffix (e.g., `-staging`, `-production`). | -| `user-workflow.workflow-owner-address` | No | Multi-sig wallet address (if applicable). Overrides the value from `project.yaml` for this specific workflow. See the `project.yaml` configuration table above for details. | -| `workflow-artifacts.workflow-path` | Yes | Path to your workflow entry point. For TypeScript: `"./main.ts"` (or your entry file name). For Go: `"."` (current directory). | -| `workflow-artifacts.config-path` | Yes | Path to your workflow configuration JSON file (e.g., `"./config.staging.json"` or `"./config.production.json"`). | -| `workflow-artifacts.secrets-path` | No | Path to your secrets YAML file (e.g., `"../secrets.yaml"`). Use `""` (empty string) if not using secrets. See [Secrets Management](/cre/guides/workflow/secrets) for details. | +| Field | Required | Description | +| -------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `user-workflow.workflow-name` | Yes | The name of your workflow. This name is used to identify the workflow when deploying, activating, or managing it via CLI commands. Best practice: include environment suffix (e.g., `-staging`, `-production`). | +| `user-workflow.workflow-owner-address` | No | Multi-sig wallet address (if applicable). Overrides the value from `project.yaml` for this specific workflow. See the `project.yaml` configuration table above for details. | +| `user-workflow.deployment-registry` | No | Selects which registry receives this target's deployment. Defaults to `"private"` (Chainlink-hosted; managed with your CRE login, no wallet required). Set to `"onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry contract — this requires a [linked web3 key](/cre/organization/linking-keys) and a funded wallet. Run [`cre registry list`](/cre/reference/cli/registry) to see registries available. | +| `workflow-artifacts.workflow-path` | Yes | Path to your workflow entry point. For TypeScript: `"./main.ts"` (or your entry file name). For Go: `"."` (current directory). | +| `workflow-artifacts.config-path` | Yes | Path to your workflow configuration JSON file (e.g., `"./config.staging.json"` or `"./config.production.json"`). | +| `workflow-artifacts.secrets-path` | No | Path to your secrets YAML file (e.g., `"../secrets.yaml"`). Use `""` (empty string) if not using secrets. See [Secrets Management](/cre/guides/workflow/secrets) for details. | {/* prettier-ignore */} - -1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. By default, deployments go to the Chainlink-hosted private registry using your CRE login — no wallet required. -2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry. +1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. Set `deployment-registry` in `workflow.yaml` to choose private registry management or the public onchain Workflow Registry. +2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"`. 3. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers @@ -10434,7 +10632,7 @@ Before you begin, ensure you have the following: - **CRE CLI**: See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) for details. - **CRE account & authentication**: You must have a CRE account and be logged in with the CLI. See [Create your account](/cre/account/creating-account) and [Log in with the CLI](/cre/account/cli-login) for instructions. - **Go**: You must have Go version 1.25.3 or higher installed. Check your version with go version. See [Install Go](https://go.dev/doc/install) for instructions. -- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the default `private` registry. Go to faucets.chain.link to get some Sepolia ETH. +- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -16367,11 +16565,11 @@ myProject/ │ ├── abi/ # Contract ABI files (.abi JSON format) │ └── generated/ # Auto-generated Go bindings ├── workflow1/ -│ ├── workflow.yaml # Workflow-specific configuration (optional) +│ ├── workflow.yaml # Workflow-specific configuration │ ├── main.go # Your workflow code │ └── … ├── workflow2/ -│ ├── workflow.yaml # Workflow-specific configuration (optional) +│ ├── workflow.yaml # Workflow-specific configuration │ ├── main.go # Your workflow code │ └── … └── … @@ -16379,7 +16577,7 @@ myProject/ - `go.mod` / `go.sum`: **Go module definition** and dependency management for the entire project. - `project.yaml`: **Global settings**, shared by every workflow in the project. -- `workflow.yaml`: **Local settings** for a single workflow. Add this file only when the workflow needs overrides. +- `workflow.yaml`: **Local settings** for a single workflow. Define each target's `workflow-name`, `deployment-registry`, workflow artifacts, and any workflow-specific overrides here. - `secrets.yaml`: **Secret declarations**, a manifest of logical secret names used across the project. - `contracts/evm/src/abi/`: **Contract ABIs**, where you place `.abi` JSON files for contract binding generation. - `contracts/evm/src/generated/`: **Generated Go bindings**, automatically created by the CRE CLI from your ABI files using `cre generate-bindings`. @@ -16446,12 +16644,12 @@ Variable values are resolved from environment variables at runtime. This works a `workflow.yaml` captures details **unique to one workflow instance**, like its name. - - -Changes the workflow status to paused on the Workflow Registry contract. Paused workflows will not respond to triggers. +Changes the workflow status to paused in the registry selected by `deployment-registry`. Paused workflows will not respond to triggers. **Usage:** @@ -8675,10 +8868,10 @@ cre workflow pause [flags] **Flags:** -| Flag | Description | -| ------------ | --------------------------------------------------------------- | -| `--unsigned` | Return the raw transaction instead of sending it to the network | -| `--yes` | Skip the confirmation prompt and proceed with the operation | +| 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:** @@ -8701,7 +8894,7 @@ For more details, see [Activating & Pausing Workflows](/cre/guides/operations/ac in with the CLI](/cre/account/cli-login) for further details. -Deletes a workflow from the Workflow Registry. +Deletes a workflow from the registry selected by `deployment-registry`. **Usage:** @@ -8715,10 +8908,10 @@ cre workflow delete [flags] **Flags:** -| Flag | Description | -| ------------ | --------------------------------------------------------------- | -| `--unsigned` | Return the raw transaction instead of sending it to the network | -| `--yes` | Skip the confirmation prompt and proceed with the operation | +| 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:** @@ -8950,7 +9143,12 @@ The `cre registry` commands let you view and inspect the workflow registries ava ## What is a workflow registry? -A **workflow registry** is the system that tracks which workflows are registered to your CRE organization and makes them available to the DON (Decentralized Oracle Network) for execution. The standard registry is a smart contract on Ethereum Mainnet — when you run `cre workflow deploy`, the CLI submits a transaction to that contract recording your workflow's name, owner, and artifact URLs, and the DON reads from it to discover and execute your workflow. +A **workflow registry** is the system that tracks which workflows are registered to your CRE organization and makes them available to the DON (Decentralized Oracle Network) for execution. CRE supports a public onchain registry and a private Chainlink-hosted registry. + +- **Public/onchain registry**: A smart contract on Ethereum Mainnet. When you run `cre workflow deploy`, the CLI submits a transaction to that contract recording your workflow's name, owner, and artifact URLs. +- **Private registry**: A centralized, offchain registry hosted by Chainlink. Workflow management is authorized by your CRE login session instead of a linked wallet key. + +Private registry management is a control-plane choice. It does not make workflow execution confidential, and confidential execution does not require the private registry. When you log in with `cre login`, the CLI fetches your organization's registry configuration from the CRE platform and caches it locally in `~/.cre/context.yaml`. `cre registry list` reads from that cache and shows which registries your organization has access to. @@ -8966,7 +9164,7 @@ When you log in with `cre login`, the CLI fetches your organization's registry c ## `cre registry list` -Displays the workflow registries configured for your organization, including each registry's label, ID, type, and on-chain address (where applicable). Registry data is sourced from `~/.cre/context.yaml`, which is fetched from the CRE platform when you run `cre login`. +Displays the workflow registries configured for your organization, including each registry's label, ID, type, and onchain address (where applicable). Registry data is sourced from `~/.cre/context.yaml`, which is fetched from the CRE platform when you run `cre login`. **Usage:** @@ -8981,15 +9179,15 @@ Registries available to your organization ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet - Type: on-chain + Type: onchain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 Private (Chainlink-hosted) ID: private - Type: off-chain + Type: offchain ``` -The `ID` value is what you put in the `user-workflow.deployment-registry` field of your `workflow.yaml` to target that registry on `cre workflow deploy`. See [Project Configuration](/cre/reference/project-configuration#3-2-workflow-configuration-workflow-yaml) and [Deploying Workflows](/cre/guides/operations/deploying-workflows#choosing-your-registry). +The `ID` value is what you put in the required `user-workflow.deployment-registry` field of your `workflow.yaml` to target that registry on `cre workflow deploy`. See [Project Configuration](/cre/reference/project-configuration#3-2-workflow-configuration-workflow-yaml) and [Deploying Workflows](/cre/guides/operations/deploying-workflows#choosing-your-registry). If no registries are found for your environment, the command prints a warning and exits cleanly. @@ -9014,9 +9212,9 @@ The `cre secrets` commands manage secrets stored in the Vault DON (Decentralized ## Auth modes -`cre secrets` supports two authorization modes, mirroring the [control plane split](/cre/guides/operations/deploying-workflows#control-plane-web3-key-vs-auth-only) used for workflow deployment: +`cre secrets` supports two authorization modes, mirroring the [private vs. public workflow management split](/cre/guides/operations/deploying-workflows#private-vs-public-workflow-management) used for workflow deployment: -- **Web3-keyed (default).** Each operation is tied to your linked `workflow-owner-address`. Use this when your workflow is deployed to the on-chain registry (`deployment-registry: "onchain:ethereum-mainnet"`). +- **Web3-keyed.** Each operation is tied to your linked `workflow-owner-address`. Use this when your workflow is deployed to the onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`). - **Browser auth (`--secrets-auth=browser`).** Each operation is authorized through a browser-based OAuth (PKCE) flow against the Vault DON gateway, using your CRE login session. No wallet or `workflow-owner-address` required. Use this when your workflow is deployed to the `private` registry, or when secrets are owned at the organization level. Pass `--secrets-auth=browser` on any of `cre secrets create | update | delete | list` to opt into browser auth for that command. If omitted, the CLI uses the default for your target. @@ -9060,8 +9258,8 @@ Secrets are organized into **namespaces**, which act as logical groupings (e.g., @@ -10177,8 +10375,8 @@ Here are resources to help you go from simulation to production. Deploying requires Early Access approval. Run `cre account access` or visit app.chain.link/cre/request-access to submit a request. See [Requesting Deploy Access](/cre/account/deploy-access). While you wait, continue building and simulating workflows. -1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. By default, deployments go to the Chainlink-hosted private registry using your CRE login — no wallet required. -2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"` to deploy to the on-chain Workflow Registry. +1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. Set `deployment-registry` in `workflow.yaml` to choose private registry management or the public onchain Workflow Registry. +2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"`. 3. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers @@ -10327,7 +10525,7 @@ Before you begin, ensure you have the following: - **CRE CLI**: See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) for details. - **CRE account & authentication**: You must have a CRE account and be logged in with the CLI. See [Create your account](/cre/account/creating-account) and [Log in with the CLI](/cre/account/cli-login) for instructions. - **Bun**: You must have Bun version 1.2.21 or higher installed. Check your version with bun --version. See [Install Bun](https://bun.com) for instructions. -- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the default `private` registry. Go to faucets.chain.link to get some Sepolia ETH. +- **Funded Sepolia Account**: An account with Sepolia ETH to pay for transaction gas fees. Required for [Part 4: Writing Onchain](/cre/getting-started/part-4-writing-onchain), and for any deployment that uses `deployment-registry: "onchain:ethereum-mainnet"`. Not required to simulate workflows or deploy to the `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -16221,7 +16419,7 @@ myProject/ │ ├── tsconfig.json # TypeScript configuration │ ├── bun.lock # Dependency lock file │ ├── node_modules/ # Installed dependencies -│ ├── workflow.yaml # Workflow-specific configuration (optional) +│ ├── workflow.yaml # Workflow-specific configuration │ ├── main.ts # Your workflow code │ └── … ├── workflow2/ @@ -16229,14 +16427,14 @@ myProject/ │ ├── tsconfig.json # TypeScript configuration │ ├── bun.lock # Dependency lock file │ ├── node_modules/ # Installed dependencies -│ ├── workflow.yaml # Workflow-specific configuration (optional) +│ ├── workflow.yaml # Workflow-specific configuration │ ├── main.ts # Your workflow code │ └── … └── … ``` - `project.yaml`: **Global settings**, shared by every workflow in the project. -- `workflow.yaml`: **Local settings** for a single workflow. Add this file only when the workflow needs overrides. +- `workflow.yaml`: **Local settings** for a single workflow. Define each target's `workflow-name`, `deployment-registry`, workflow artifacts, and any workflow-specific overrides here. - `secrets.yaml`: **Secret declarations**, a manifest of logical secret names used across the project. - `contracts/abi/`: **TypeScript ABI definitions**, where you place `.ts` files that export contract ABIs using viem's type system. Unlike Go, TypeScript doesn't require generating bindings—ABIs are used directly with viem. - `package.json` / `tsconfig.json`: **Workflow-specific dependencies and TypeScript configuration**. Each workflow manages its own dependencies independently. @@ -16304,12 +16502,12 @@ Variable values are resolved from environment variables at runtime. This works a `workflow.yaml` captures details **unique to one workflow instance**, like its name and entry point file. - -Changes the workflow status to active on the Workflow Registry contract. Active workflows can respond to their configured triggers. +Changes the workflow status to active in the registry selected by `deployment-registry`. Active workflows can respond to their configured triggers. **Usage:** @@ -215,10 +215,10 @@ cre workflow activate [flags] **Flags:** -| Flag | Description | -| ------------ | --------------------------------------------------------------- | -| `--unsigned` | Return the raw transaction instead of sending it to the network | -| `--yes` | Skip the confirmation prompt and proceed with the operation | +| 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:** @@ -236,7 +236,7 @@ For more details, see [Activating & Pausing Workflows](/cre/guides/operations/ac in with the CLI](/cre/account/cli-login) for further details. -Changes the workflow status to paused on the Workflow Registry contract. Paused workflows will not respond to triggers. +Changes the workflow status to paused in the registry selected by `deployment-registry`. Paused workflows will not respond to triggers. **Usage:** @@ -250,10 +250,10 @@ cre workflow pause [flags] **Flags:** -| Flag | Description | -| ------------ | --------------------------------------------------------------- | -| `--unsigned` | Return the raw transaction instead of sending it to the network | -| `--yes` | Skip the confirmation prompt and proceed with the operation | +| 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:** @@ -276,7 +276,7 @@ For more details, see [Activating & Pausing Workflows](/cre/guides/operations/ac in with the CLI](/cre/account/cli-login) for further details. -Deletes a workflow from the Workflow Registry. +Deletes a workflow from the registry selected by `deployment-registry`. **Usage:** @@ -290,10 +290,10 @@ cre workflow delete [flags] **Flags:** -| Flag | Description | -| ------------ | --------------------------------------------------------------- | -| `--unsigned` | Return the raw transaction instead of sending it to the network | -| `--yes` | Skip the confirmation prompt and proceed with the operation | +| 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:** diff --git a/src/content/cre/reference/project-configuration-go.mdx b/src/content/cre/reference/project-configuration-go.mdx index 5affc92515c..3e9e6e480d3 100644 --- a/src/content/cre/reference/project-configuration-go.mdx +++ b/src/content/cre/reference/project-configuration-go.mdx @@ -52,11 +52,11 @@ myProject/ │ ├── abi/ # Contract ABI files (.abi JSON format) │ └── generated/ # Auto-generated Go bindings ├── workflow1/ -│ ├── workflow.yaml # Workflow-specific configuration (optional) +│ ├── workflow.yaml # Workflow-specific configuration │ ├── main.go # Your workflow code │ └── … ├── workflow2/ -│ ├── workflow.yaml # Workflow-specific configuration (optional) +│ ├── workflow.yaml # Workflow-specific configuration │ ├── main.go # Your workflow code │ └── … └── … @@ -64,7 +64,7 @@ myProject/ - `go.mod` / `go.sum`: **Go module definition** and dependency management for the entire project. - `project.yaml`: **Global settings**, shared by every workflow in the project. -- `workflow.yaml`: **Local settings** for a single workflow. Add this file only when the workflow needs overrides. +- `workflow.yaml`: **Local settings** for a single workflow. Define each target's `workflow-name`, `deployment-registry`, workflow artifacts, and any workflow-specific overrides here. - `secrets.yaml`: **Secret declarations**, a manifest of logical secret names used across the project. - `contracts/evm/src/abi/`: **Contract ABIs**, where you place `.abi` JSON files for contract binding generation. - `contracts/evm/src/generated/`: **Generated Go bindings**, automatically created by the CRE CLI from your ABI files using `cre generate-bindings`. @@ -131,12 +131,12 @@ Variable values are resolved from environment variables at runtime. This works a `workflow.yaml` captures details **unique to one workflow instance**, like its name. - -{/* prettier-ignore */} - - 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/key-terms#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"`. @@ -68,7 +36,7 @@ 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](/cre/account/deploy-access). - **[Authenticated](/cre/reference/cli/authentication)**: Logged in via `cre login` or using an [API key](/cre/reference/cli/authentication#api-key-authentication) (`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`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: New in CRE CLI v1.14.0. When omitted, the CLI defaults to the public onchain Workflow Registry (existing behavior). Set this field to `"private"` to use the Chainlink-hosted private registry, or to `"onchain:ethereum-mainnet"` to explicitly target the onchain registry. Run `cre registry list` to see which registries are available to your organization. - **(Onchain registry only) [Linked your key](/cre/reference/cli/account#cre-account-link-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. @@ -87,12 +55,12 @@ Registries available to your organization ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet - Type: onchain + Type: on-chain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 Private (Chainlink-hosted) ID: private - Type: offchain + Type: off-chain ``` Use the `ID` value as the value of `deployment-registry` in your `workflow.yaml`. @@ -127,100 +95,9 @@ Use this flow when `deployment-registry: "private"`: 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`: - -```yaml -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: - -```text -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: - -```bash -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:** +For a complete step-by-step walkthrough, see [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry). -```yaml -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:** - -```yaml -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: - -```bash -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. +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`). ## The deployment process @@ -239,7 +116,7 @@ Chainlink Runtime Environment (CRE) deployment is in the "Early Access" stage of ### 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. +Before deploying, ensure your `workflow.yaml` file is correctly configured. The `workflow-name` field is required under the `user-workflow` section for your target environment. The `deployment-registry` field is optional — when omitted, the CLI defaults to the public onchain Workflow Registry. 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`. @@ -468,6 +345,7 @@ For complete setup instructions, configuration requirements, and step-by-step gu ## Next steps +- [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry): Step-by-step guide for using the Chainlink-hosted private registry - [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows): Learn how to control workflow execution - [Monitoring Workflows](/cre/guides/operations/monitoring-workflows): Track your workflow's execution and performance - [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows): Deploy new versions of your workflow diff --git a/src/content/cre/guides/operations/updating-deployed-workflows.mdx b/src/content/cre/guides/operations/updating-deployed-workflows.mdx index 05c586e27f5..23a5354dd4f 100644 --- a/src/content/cre/guides/operations/updating-deployed-workflows.mdx +++ b/src/content/cre/guides/operations/updating-deployed-workflows.mdx @@ -25,7 +25,7 @@ Before updating a deployed workflow, ensure you have: - **Workflow authorization**: You must be authorized to manage the workflow. Public onchain registry workflows use the linked workflow owner address. Private registry workflows use your CRE organization login session. - **Local workflow folder**: You must run this command from your project directory. The CLI reads the workflow name and configuration from your `workflow.yaml` file to identify which workflow to update. - **[Logged in](/cre/reference/cli/authentication#cre-login)**: Authenticated with the platform by running `cre login`. To check if you are logged in, run `cre whoami`. -- **A `deployment-registry` value**: Updated CLI-generated targets use `private` by default. For older workflow files, make sure the target has `deployment-registry: "private"` or `deployment-registry: "onchain:ethereum-mainnet"`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: When omitted, the CLI uses the default onchain registry. Set to `"private"` to manage the workflow via the Chainlink-hosted private registry. See [Choosing your registry](/cre/guides/operations/deploying-workflows#choosing-your-registry). - **(Onchain registry only) A funded wallet**: The account must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction. ## Updating a workflow diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index 78806a25f94..69a583928aa 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -280,6 +280,23 @@ This page documents the service quotas for Chainlink Runtime Environment (CRE) w The quotas documented on this page are subject to change. Check back regularly for updates. +## Per-organization quotas + +These quotas apply at the organization level. + +### Registry quotas + +| Registry | Quota | Value | +| --------------------------------------------------------------------------- | ------------------------------------ | ----- | +| Private registry (`deployment-registry: "private"`) | Maximum workflows per organization | 3 | +| Public onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`) | Maximum linked keys per organization | 1 | +| Public onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`) | Maximum workflows per linked key | 3 | + + + + ## Per-owner quotas These quotas apply to each workflow owner (user account) within an organization. @@ -5810,37 +5827,6 @@ Last Updated: 2026-04-30 **While you wait:** Continue building and simulating workflows using [`cre workflow simulate`](/cre/guides/operations/simulating-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/key-terms#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"`. @@ -5859,7 +5845,7 @@ 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](/cre/account/deploy-access). - **[Authenticated](/cre/reference/cli/authentication)**: Logged in via `cre login` or using an [API key](/cre/reference/cli/authentication#api-key-authentication) (`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`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: New in CRE CLI v1.14.0. When omitted, the CLI defaults to the public onchain Workflow Registry (existing behavior). Set this field to `"private"` to use the Chainlink-hosted private registry, or to `"onchain:ethereum-mainnet"` to explicitly target the onchain registry. Run `cre registry list` to see which registries are available to your organization. - **(Onchain registry only) [Linked your key](/cre/reference/cli/account#cre-account-link-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. @@ -5878,12 +5864,12 @@ Registries available to your organization ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet - Type: onchain + Type: on-chain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 Private (Chainlink-hosted) ID: private - Type: offchain + Type: off-chain ``` Use the `ID` value as the value of `deployment-registry` in your `workflow.yaml`. @@ -5918,100 +5904,9 @@ Use this flow when `deployment-registry: "private"`: 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`: - -```yaml -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: - -```text -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: - -```bash -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:** - -```yaml -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:** - -```yaml -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 +For a complete step-by-step walkthrough, see [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry). -After the YAML is updated, rerun the command that failed: - -```bash -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. +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`). ## The deployment process @@ -6030,7 +5925,7 @@ The `cre workflow deploy` command handles the entire end-to-end process for you: ### 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. +Before deploying, ensure your `workflow.yaml` file is correctly configured. The `workflow-name` field is required under the `user-workflow` section for your target environment. The `deployment-registry` field is optional — when omitted, the CLI defaults to the public onchain Workflow Registry. 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`. @@ -6259,12 +6154,297 @@ For complete setup instructions, configuration requirements, and step-by-step gu ## Next steps +- [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry): Step-by-step guide for using the Chainlink-hosted private registry - [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows): Learn how to control workflow execution - [Monitoring Workflows](/cre/guides/operations/monitoring-workflows): Track your workflow's execution and performance - [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows): Deploy new versions of your workflow --- +# Deploying to the Private Registry +Source: https://docs.chain.link/cre/guides/operations/deploying-to-private-registry +Last Updated: 2026-05-06 + + + +The **private registry** is a Chainlink-hosted, offchain workflow registry available as of CRE CLI v1.14.0. Deploying to it works identically to the public onchain registry, with one key difference: all lifecycle operations (deploy, activate, pause, delete, update) are authorized by your CRE login session — not a linked wallet key. There are no Ethereum Mainnet transactions and no gas fees for registry management. + + + + +## Prerequisites + +Before deploying to the private registry, ensure you have: + +- **CRE CLI v1.14.0 or later**: Run `cre version` to check. See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) to install or update. +- **Early Access approval**: Run `cre account access` to check your status. See [Requesting Deploy Access](/cre/account/deploy-access). +- **[Logged in](/cre/account/cli-login)**: Run `cre login` and complete the browser authentication flow. API keys also work: set `CRE_API_KEY` in your environment. +- **Private registry enabled for your organization**: Run `cre registry list` and confirm a registry with `Type: off-chain` appears in the output (see [Step 1](#step-1-confirm-the-private-registry-is-available) below). Organizations are limited to **3 private registry workflows** by default. See [Service Quotas](/cre/service-quotas#registry-quotas). +- **A workflow project**: An existing project created with `cre init`. See [Part 1: Project Setup](/cre/getting-started/part-1-project-setup-ts) for the TypeScript guide or [Go guide](/cre/getting-started/part-1-project-setup-go). + +Unlike the public onchain registry, you do **not** need: + +- A linked wallet key (`cre account link-key`) +- `CRE_ETH_PRIVATE_KEY` in your `.env` file +- An Ethereum Mainnet RPC URL in `project.yaml` +- ETH for gas + +## Step 1: Confirm the private registry is available + +Run `cre registry list` to see the registries available to your organization: + +```bash +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 +``` + +You need to see a registry with `Type: off-chain` before proceeding. If no private registry appears, your organization has not been provisioned access yet. Contact your Chainlink account team. + +## Step 2: Add `deployment-registry` to your `workflow.yaml` + +Open your workflow's `workflow.yaml` and add `deployment-registry: "private"` under the `user-workflow` section for the target you want to deploy to: + +**TypeScript:** + +```yaml +# workflow.yaml +staging-settings: + user-workflow: + workflow-name: "my-workflow-staging" + deployment-registry: "private" + workflow-artifacts: + workflow-path: "./main.ts" + config-path: "./config.staging.json" + secrets-path: "" +``` + +**Go:** + +```yaml +# workflow.yaml +staging-settings: + user-workflow: + workflow-name: "my-workflow-staging" + deployment-registry: "private" + workflow-artifacts: + workflow-path: "." + config-path: "./config.staging.json" + secrets-path: "" +``` + +The `deployment-registry` field is optional. When omitted, the CLI uses the default public onchain Workflow Registry. Setting it to `"private"` routes all lifecycle operations for that target through the Chainlink-hosted private registry. + + + + +## Step 3: Deploy the workflow + +From your project root, run the deploy command with your target: + +```bash +cre workflow deploy my-workflow --target staging-settings +``` + +The CLI compiles your workflow, uploads the artifacts to the CRE Storage Service, and registers the workflow with the private registry using your CRE login session. There is no transaction prompt. + +**Example output:** + +``` +Deploying Workflow : my-workflow +Target : staging-settings +Owner Address : + +Compiling workflow... +Workflow compiled successfully + +Uploading files... +✔ Loaded binary from: ./binary.wasm.br.b64 +✔ Uploaded binary to: https://storage.cre.example.com/artifacts//binary.wasm +✔ Loaded config from: ./config.staging.json +✔ Uploaded config to: https://storage.cre.example.com/artifacts//config + +Registering workflow in private registry (workflowID: )... +✓ Workflow registered in private registry + +Details: + Registry: private + Workflow Name: my-workflow + Workflow ID: + Status: Active + Binary URL: https://storage.cre.example.com/artifacts//binary.wasm + Config URL: https://storage.cre.example.com/artifacts//config + Owner: +``` + +The workflow is registered and active immediately. Notice there is no transaction hash, no gas cost, and the `Owner` is your CRE organization rather than a wallet address. + +## Step 4: Verify the deployment + +Run `cre workflow list` to confirm the workflow appears and is registered to the private registry: + +```bash +cre workflow list +``` + +Workflows deployed to the private registry are tagged with the registry ID `private` in the list output. You can also filter to only show private registry workflows: + +```bash +cre workflow list --registry private +``` + +You can also view the workflow in the [CRE platform](https://app.chain.link/cre/discover) under **Workflows**. + +## Managing a private registry workflow + +All standard lifecycle commands work the same way for private registry workflows. The CLI routes the operation through the Chainlink-hosted registry automatically based on the `deployment-registry` value in your `workflow.yaml`. + +### Activate + +```bash +cre workflow activate my-workflow --target staging-settings +``` + +**Example output:** + +``` +Fetching workflow to activate... Name=my-workflow + +Processing activation for workflow ID ... +✓ Workflow activated successfully + +Details: + Registry: private + Workflow Name: my-workflow + Workflow ID: + Status: Active + Owner: +``` + +### Pause + +```bash +cre workflow pause my-workflow --target staging-settings +``` + +**Example output:** + +``` +Fetching workflow to pause... Name=my-workflow + +Processing pause for workflow ID ... +✓ Workflow paused successfully + +Details: + Registry: private + Workflow Name: my-workflow + Workflow ID: + Status: Paused + Owner: +``` + +### Update + +Redeploy with the same workflow name to update a private registry workflow. The CLI replaces the existing registration: + +```bash +cre workflow deploy my-workflow --target staging-settings +``` + +The CLI prompts you to confirm before overwriting the existing workflow. Pass `--yes` to skip the prompt. + +### Delete + +```bash +cre workflow delete my-workflow --target staging-settings +``` + +The CLI fetches the workflow, displays its details, and prompts you to type the workflow name to confirm. This action is permanent. + + + + +## Secrets with the private registry + +Secrets for private registry workflows are authorized through a browser-based OAuth (PKCE) flow rather than your linked wallet key. Use the `--secrets-auth=browser` flag on any `cre secrets` command: + +```bash +# Create secrets for a private registry workflow +cre secrets create secrets.yaml --target staging-settings --secrets-auth=browser + +# Update secrets +cre secrets update secrets.yaml --target staging-settings --secrets-auth=browser + +# List secrets +cre secrets list --target staging-settings --secrets-auth=browser +``` + +When you pass `--secrets-auth=browser`, the CLI opens a browser window to authorize the operation against the Vault DON using your CRE login session. No wallet, no `workflow-owner-address`, and no gas are required. + +See [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) for the full secrets guide. + +## CI/CD with the private registry + +Because the private registry does not require `CRE_ETH_PRIVATE_KEY` or an Ethereum Mainnet RPC, CI/CD pipelines are simpler. You only need `CRE_API_KEY`: + +```yaml +# .github/workflows/deploy-private.yml +name: Deploy to Private Registry + +on: + push: + branches: [main] + +jobs: + deploy: + 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: Deploy workflow + run: cre workflow deploy ./my-workflow --target staging-settings --yes --non-interactive + env: + CRE_API_KEY: ${{ secrets.CRE_API_KEY }} +``` + + + + +## Next steps + +- [Deploying Workflows](/cre/guides/operations/deploying-workflows) — Overview of both registry options and the full deployment process +- [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows) — Control workflow execution state +- [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) — Manage secrets for deployed workflows +- [Registry Commands Reference](/cre/reference/cli/registry) — `cre registry list` and related commands + +--- + # Activating & Pausing Workflows Source: https://docs.chain.link/cre/guides/operations/activating-pausing-workflows Last Updated: 2025-11-04 @@ -6284,7 +6464,7 @@ Before activating or pausing workflows, ensure you have: - **Workflow authorization**: You must be authorized to manage the workflow. Public onchain registry workflows use the linked workflow owner address. Private registry workflows use your CRE organization login session. - **Local workflow folder**: You must run these commands from your project directory. The CLI reads the workflow name and configuration from your `workflow.yaml` file to identify which workflow to activate or pause. - **[Logged in](/cre/reference/cli/authentication#cre-login)**: Authenticated with the platform by running `cre login`. To check your authentication status, run `cre whoami`. -- **A `deployment-registry` value**: Updated CLI-generated targets use `private` by default. For older workflow files, make sure the target has `deployment-registry: "private"` or `deployment-registry: "onchain:ethereum-mainnet"`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: When omitted, the CLI uses the default onchain registry. Set to `"private"` to manage the workflow via the Chainlink-hosted private registry. See [Choosing your registry](/cre/guides/operations/deploying-workflows#choosing-your-registry). - **(Onchain registry only) A funded wallet**: The account you are using must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction. ## Activating a workflow @@ -6455,7 +6635,7 @@ Before updating a deployed workflow, ensure you have: - **Workflow authorization**: You must be authorized to manage the workflow. Public onchain registry workflows use the linked workflow owner address. Private registry workflows use your CRE organization login session. - **Local workflow folder**: You must run this command from your project directory. The CLI reads the workflow name and configuration from your `workflow.yaml` file to identify which workflow to update. - **[Logged in](/cre/reference/cli/authentication#cre-login)**: Authenticated with the platform by running `cre login`. To check if you are logged in, run `cre whoami`. -- **A `deployment-registry` value**: Updated CLI-generated targets use `private` by default. For older workflow files, make sure the target has `deployment-registry: "private"` or `deployment-registry: "onchain:ethereum-mainnet"`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: When omitted, the CLI uses the default onchain registry. Set to `"private"` to manage the workflow via the Chainlink-hosted private registry. See [Choosing your registry](/cre/guides/operations/deploying-workflows#choosing-your-registry). - **(Onchain registry only) A funded wallet**: The account must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction. ## Updating a workflow @@ -6519,7 +6699,7 @@ Before deleting a workflow, ensure you have: - **Workflow authorization**: You must be authorized to manage the workflow. Public onchain registry workflows use the linked workflow owner address. Private registry workflows use your CRE organization login session. - **Local workflow folder**: You must run this command from your project directory. The CLI reads the workflow name and configuration from your `workflow.yaml` file to identify which workflow to delete. - **[Logged in](/cre/reference/cli/authentication#cre-login)**: Authenticated with the platform by running `cre login`. To check if you are logged in, run `cre whoami`. -- **A `deployment-registry` value**: Updated CLI-generated targets use `private` by default. For older workflow files, make sure the target has `deployment-registry: "private"` or `deployment-registry: "onchain:ethereum-mainnet"`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: When omitted, the CLI uses the default onchain registry. Set to `"private"` to manage the workflow via the Chainlink-hosted private registry. See [Choosing your registry](/cre/guides/operations/deploying-workflows#choosing-your-registry). - **(Onchain registry only) A funded wallet**: The account must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction. ## Deleting a workflow @@ -9645,15 +9825,15 @@ Registries available to your organization ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet - Type: onchain + Type: on-chain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 Private (Chainlink-hosted) ID: private - Type: offchain + Type: off-chain ``` -The `ID` value is what you put in the required `user-workflow.deployment-registry` field of your `workflow.yaml` to target that registry on `cre workflow deploy`. See [Project Configuration](/cre/reference/project-configuration#3-2-workflow-configuration-workflow-yaml) and [Deploying Workflows](/cre/guides/operations/deploying-workflows#choosing-your-registry). +The `ID` value is what you put in the optional `user-workflow.deployment-registry` field of your `workflow.yaml` to target that registry on `cre workflow deploy`. See [Project Configuration](/cre/reference/project-configuration#3-2-workflow-configuration-workflow-yaml) and [Deploying Workflows](/cre/guides/operations/deploying-workflows#choosing-your-registry). If no registries are found for your environment, the command prints a warning and exits cleanly. @@ -10560,8 +10740,8 @@ Here are resources to help you go from simulation to production. Deploying requires Early Access approval. Run `cre account access` or visit app.chain.link/cre/request-access to submit a request. See [Requesting Deploy Access](/cre/account/deploy-access). While you wait, continue building and simulating workflows. -1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. Set `deployment-registry` in `workflow.yaml` to choose private registry management or the public onchain Workflow Registry. -2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"`. +1. **[Link a Wallet Key](/cre/organization/linking-keys)** — Required for the default onchain Workflow Registry. Not needed when using `deployment-registry: "private"`. +2. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. Optionally set `deployment-registry: "private"` in `workflow.yaml` to use the Chainlink-hosted private registry (no linked key or gas required for registry operations). 3. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers @@ -10762,6 +10942,7 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera - **Language**: Select `Golang` and press Enter. - **Pick a workflow template**: Use the arrow keys to select `Helloworld: A Golang Hello World example` and press Enter. We are starting from scratch to learn all the configuration steps. - **Workflow name**: my-calculator-workflow + - **Deployment registry**: Select your preferred registry. Private (off-chain) registries appear first — choose `private` for quick testing without a wallet or gas, or `onchain:ethereum-mainnet` for the public Workflow Registry. If no registries appear, this step is skipped. The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it. @@ -16261,14 +16442,15 @@ cre init [flags] **Flags:** -| Flag | Description | -| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | -| `--non-interactive` | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments). | -| `-p, --project-name` | Name for the new project (required for a new project when using `--non-interactive`). | -| `-t, --template` | Template name to use (for example `hello-world-go`). Run `cre templates list` to see IDs and required networks. | -| `-w, --workflow-name` | Name for the new workflow. | -| `--refresh` | Bypass the template cache and fetch fresh data from GitHub. | -| `--rpc-url` | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. | +| Flag | Description | +| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `--non-interactive` | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments). | +| `-p, --project-name` | Name for the new project (required for a new project when using `--non-interactive`). | +| `-t, --template` | Template name to use (for example `hello-world-go`). Run `cre templates list` to see IDs and required networks. | +| `-w, --workflow-name` | Name for the new workflow. | +| `--deployment-registry` | Registry ID to write into the generated `workflow.yaml` (e.g. `private` or `onchain:ethereum-mainnet`). Run `cre registry list` to see available IDs. In `--non-interactive` mode, omitting this flag prints a warning and defaults to on-chain. | +| `--refresh` | Bypass the template cache and fetch fresh data from GitHub. | +| `--rpc-url` | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. | Inherited [global flags](/cre/reference/cli#global-flags) include **`-R, --project-root`**, which `cre init` uses as the directory where the project is created when you pass it explicitly. @@ -16280,6 +16462,7 @@ Running `cre init` without flags starts an interactive setup that guides you thr 2. **Language** (Go or TypeScript) 3. **Workflow template** (fetched dynamically from configured template sources) 4. **Workflow name** +5. **Deployment registry** — select which registry the generated `workflow.yaml` targets. Private (off-chain) registries appear first with the cursor defaulted to them. If your organization has no registries configured, this step is skipped and the field is omitted from `workflow.yaml`. +## Per-organization quotas + +These quotas apply at the organization level. + +### Registry quotas + +| Registry | Quota | Value | +| --------------------------------------------------------------------------- | ------------------------------------ | ----- | +| Private registry (`deployment-registry: "private"`) | Maximum workflows per organization | 3 | +| Public onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`) | Maximum linked keys per organization | 1 | +| Public onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`) | Maximum workflows per linked key | 3 | + + + + ## Per-owner quotas These quotas apply to each workflow owner (user account) within an organization. @@ -4909,37 +4926,6 @@ Last Updated: 2026-04-30 **While you wait:** Continue building and simulating workflows using [`cre workflow simulate`](/cre/guides/operations/simulating-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/key-terms#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"`. @@ -4958,7 +4944,7 @@ 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](/cre/account/deploy-access). - **[Authenticated](/cre/reference/cli/authentication)**: Logged in via `cre login` or using an [API key](/cre/reference/cli/authentication#api-key-authentication) (`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`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: New in CRE CLI v1.14.0. When omitted, the CLI defaults to the public onchain Workflow Registry (existing behavior). Set this field to `"private"` to use the Chainlink-hosted private registry, or to `"onchain:ethereum-mainnet"` to explicitly target the onchain registry. Run `cre registry list` to see which registries are available to your organization. - **(Onchain registry only) [Linked your key](/cre/reference/cli/account#cre-account-link-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. @@ -4977,12 +4963,12 @@ Registries available to your organization ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet - Type: onchain + Type: on-chain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 Private (Chainlink-hosted) ID: private - Type: offchain + Type: off-chain ``` Use the `ID` value as the value of `deployment-registry` in your `workflow.yaml`. @@ -5017,100 +5003,9 @@ Use this flow when `deployment-registry: "private"`: 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`: - -```yaml -staging-settings: - user-workflow: - workflow-name: "my-workflow-staging" - workflow-artifacts: - workflow-path: "./main.ts" - config-path: "./config.staging.json" -``` +For a complete step-by-step walkthrough, see [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry). -After upgrading, the CLI reports the missing field and points to the target that needs the update: - -```text -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: - -```bash -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:** - -```yaml -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:** - -```yaml -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: - -```bash -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. +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`). ## The deployment process @@ -5129,7 +5024,7 @@ The `cre workflow deploy` command handles the entire end-to-end process for you: ### 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. +Before deploying, ensure your `workflow.yaml` file is correctly configured. The `workflow-name` field is required under the `user-workflow` section for your target environment. The `deployment-registry` field is optional — when omitted, the CLI defaults to the public onchain Workflow Registry. 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`. @@ -5358,12 +5253,297 @@ For complete setup instructions, configuration requirements, and step-by-step gu ## Next steps +- [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry): Step-by-step guide for using the Chainlink-hosted private registry - [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows): Learn how to control workflow execution - [Monitoring Workflows](/cre/guides/operations/monitoring-workflows): Track your workflow's execution and performance - [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows): Deploy new versions of your workflow --- +# Deploying to the Private Registry +Source: https://docs.chain.link/cre/guides/operations/deploying-to-private-registry +Last Updated: 2026-05-06 + + + +The **private registry** is a Chainlink-hosted, offchain workflow registry available as of CRE CLI v1.14.0. Deploying to it works identically to the public onchain registry, with one key difference: all lifecycle operations (deploy, activate, pause, delete, update) are authorized by your CRE login session — not a linked wallet key. There are no Ethereum Mainnet transactions and no gas fees for registry management. + + + + +## Prerequisites + +Before deploying to the private registry, ensure you have: + +- **CRE CLI v1.14.0 or later**: Run `cre version` to check. See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) to install or update. +- **Early Access approval**: Run `cre account access` to check your status. See [Requesting Deploy Access](/cre/account/deploy-access). +- **[Logged in](/cre/account/cli-login)**: Run `cre login` and complete the browser authentication flow. API keys also work: set `CRE_API_KEY` in your environment. +- **Private registry enabled for your organization**: Run `cre registry list` and confirm a registry with `Type: off-chain` appears in the output (see [Step 1](#step-1-confirm-the-private-registry-is-available) below). Organizations are limited to **3 private registry workflows** by default. See [Service Quotas](/cre/service-quotas#registry-quotas). +- **A workflow project**: An existing project created with `cre init`. See [Part 1: Project Setup](/cre/getting-started/part-1-project-setup-ts) for the TypeScript guide or [Go guide](/cre/getting-started/part-1-project-setup-go). + +Unlike the public onchain registry, you do **not** need: + +- A linked wallet key (`cre account link-key`) +- `CRE_ETH_PRIVATE_KEY` in your `.env` file +- An Ethereum Mainnet RPC URL in `project.yaml` +- ETH for gas + +## Step 1: Confirm the private registry is available + +Run `cre registry list` to see the registries available to your organization: + +```bash +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 +``` + +You need to see a registry with `Type: off-chain` before proceeding. If no private registry appears, your organization has not been provisioned access yet. Contact your Chainlink account team. + +## Step 2: Add `deployment-registry` to your `workflow.yaml` + +Open your workflow's `workflow.yaml` and add `deployment-registry: "private"` under the `user-workflow` section for the target you want to deploy to: + +**TypeScript:** + +```yaml +# workflow.yaml +staging-settings: + user-workflow: + workflow-name: "my-workflow-staging" + deployment-registry: "private" + workflow-artifacts: + workflow-path: "./main.ts" + config-path: "./config.staging.json" + secrets-path: "" +``` + +**Go:** + +```yaml +# workflow.yaml +staging-settings: + user-workflow: + workflow-name: "my-workflow-staging" + deployment-registry: "private" + workflow-artifacts: + workflow-path: "." + config-path: "./config.staging.json" + secrets-path: "" +``` + +The `deployment-registry` field is optional. When omitted, the CLI uses the default public onchain Workflow Registry. Setting it to `"private"` routes all lifecycle operations for that target through the Chainlink-hosted private registry. + + + + +## Step 3: Deploy the workflow + +From your project root, run the deploy command with your target: + +```bash +cre workflow deploy my-workflow --target staging-settings +``` + +The CLI compiles your workflow, uploads the artifacts to the CRE Storage Service, and registers the workflow with the private registry using your CRE login session. There is no transaction prompt. + +**Example output:** + +``` +Deploying Workflow : my-workflow +Target : staging-settings +Owner Address : + +Compiling workflow... +Workflow compiled successfully + +Uploading files... +✔ Loaded binary from: ./binary.wasm.br.b64 +✔ Uploaded binary to: https://storage.cre.example.com/artifacts//binary.wasm +✔ Loaded config from: ./config.staging.json +✔ Uploaded config to: https://storage.cre.example.com/artifacts//config + +Registering workflow in private registry (workflowID: )... +✓ Workflow registered in private registry + +Details: + Registry: private + Workflow Name: my-workflow + Workflow ID: + Status: Active + Binary URL: https://storage.cre.example.com/artifacts//binary.wasm + Config URL: https://storage.cre.example.com/artifacts//config + Owner: +``` + +The workflow is registered and active immediately. Notice there is no transaction hash, no gas cost, and the `Owner` is your CRE organization rather than a wallet address. + +## Step 4: Verify the deployment + +Run `cre workflow list` to confirm the workflow appears and is registered to the private registry: + +```bash +cre workflow list +``` + +Workflows deployed to the private registry are tagged with the registry ID `private` in the list output. You can also filter to only show private registry workflows: + +```bash +cre workflow list --registry private +``` + +You can also view the workflow in the [CRE platform](https://app.chain.link/cre/discover) under **Workflows**. + +## Managing a private registry workflow + +All standard lifecycle commands work the same way for private registry workflows. The CLI routes the operation through the Chainlink-hosted registry automatically based on the `deployment-registry` value in your `workflow.yaml`. + +### Activate + +```bash +cre workflow activate my-workflow --target staging-settings +``` + +**Example output:** + +``` +Fetching workflow to activate... Name=my-workflow + +Processing activation for workflow ID ... +✓ Workflow activated successfully + +Details: + Registry: private + Workflow Name: my-workflow + Workflow ID: + Status: Active + Owner: +``` + +### Pause + +```bash +cre workflow pause my-workflow --target staging-settings +``` + +**Example output:** + +``` +Fetching workflow to pause... Name=my-workflow + +Processing pause for workflow ID ... +✓ Workflow paused successfully + +Details: + Registry: private + Workflow Name: my-workflow + Workflow ID: + Status: Paused + Owner: +``` + +### Update + +Redeploy with the same workflow name to update a private registry workflow. The CLI replaces the existing registration: + +```bash +cre workflow deploy my-workflow --target staging-settings +``` + +The CLI prompts you to confirm before overwriting the existing workflow. Pass `--yes` to skip the prompt. + +### Delete + +```bash +cre workflow delete my-workflow --target staging-settings +``` + +The CLI fetches the workflow, displays its details, and prompts you to type the workflow name to confirm. This action is permanent. + + + + +## Secrets with the private registry + +Secrets for private registry workflows are authorized through a browser-based OAuth (PKCE) flow rather than your linked wallet key. Use the `--secrets-auth=browser` flag on any `cre secrets` command: + +```bash +# Create secrets for a private registry workflow +cre secrets create secrets.yaml --target staging-settings --secrets-auth=browser + +# Update secrets +cre secrets update secrets.yaml --target staging-settings --secrets-auth=browser + +# List secrets +cre secrets list --target staging-settings --secrets-auth=browser +``` + +When you pass `--secrets-auth=browser`, the CLI opens a browser window to authorize the operation against the Vault DON using your CRE login session. No wallet, no `workflow-owner-address`, and no gas are required. + +See [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) for the full secrets guide. + +## CI/CD with the private registry + +Because the private registry does not require `CRE_ETH_PRIVATE_KEY` or an Ethereum Mainnet RPC, CI/CD pipelines are simpler. You only need `CRE_API_KEY`: + +```yaml +# .github/workflows/deploy-private.yml +name: Deploy to Private Registry + +on: + push: + branches: [main] + +jobs: + deploy: + 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: Deploy workflow + run: cre workflow deploy ./my-workflow --target staging-settings --yes --non-interactive + env: + CRE_API_KEY: ${{ secrets.CRE_API_KEY }} +``` + + + + +## Next steps + +- [Deploying Workflows](/cre/guides/operations/deploying-workflows) — Overview of both registry options and the full deployment process +- [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows) — Control workflow execution state +- [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) — Manage secrets for deployed workflows +- [Registry Commands Reference](/cre/reference/cli/registry) — `cre registry list` and related commands + +--- + # Activating & Pausing Workflows Source: https://docs.chain.link/cre/guides/operations/activating-pausing-workflows Last Updated: 2025-11-04 @@ -5383,7 +5563,7 @@ Before activating or pausing workflows, ensure you have: - **Workflow authorization**: You must be authorized to manage the workflow. Public onchain registry workflows use the linked workflow owner address. Private registry workflows use your CRE organization login session. - **Local workflow folder**: You must run these commands from your project directory. The CLI reads the workflow name and configuration from your `workflow.yaml` file to identify which workflow to activate or pause. - **[Logged in](/cre/reference/cli/authentication#cre-login)**: Authenticated with the platform by running `cre login`. To check your authentication status, run `cre whoami`. -- **A `deployment-registry` value**: Updated CLI-generated targets use `private` by default. For older workflow files, make sure the target has `deployment-registry: "private"` or `deployment-registry: "onchain:ethereum-mainnet"`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: When omitted, the CLI uses the default onchain registry. Set to `"private"` to manage the workflow via the Chainlink-hosted private registry. See [Choosing your registry](/cre/guides/operations/deploying-workflows#choosing-your-registry). - **(Onchain registry only) A funded wallet**: The account you are using must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction. ## Activating a workflow @@ -5554,7 +5734,7 @@ Before updating a deployed workflow, ensure you have: - **Workflow authorization**: You must be authorized to manage the workflow. Public onchain registry workflows use the linked workflow owner address. Private registry workflows use your CRE organization login session. - **Local workflow folder**: You must run this command from your project directory. The CLI reads the workflow name and configuration from your `workflow.yaml` file to identify which workflow to update. - **[Logged in](/cre/reference/cli/authentication#cre-login)**: Authenticated with the platform by running `cre login`. To check if you are logged in, run `cre whoami`. -- **A `deployment-registry` value**: Updated CLI-generated targets use `private` by default. For older workflow files, make sure the target has `deployment-registry: "private"` or `deployment-registry: "onchain:ethereum-mainnet"`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: When omitted, the CLI uses the default onchain registry. Set to `"private"` to manage the workflow via the Chainlink-hosted private registry. See [Choosing your registry](/cre/guides/operations/deploying-workflows#choosing-your-registry). - **(Onchain registry only) A funded wallet**: The account must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction. ## Updating a workflow @@ -5618,7 +5798,7 @@ Before deleting a workflow, ensure you have: - **Workflow authorization**: You must be authorized to manage the workflow. Public onchain registry workflows use the linked workflow owner address. Private registry workflows use your CRE organization login session. - **Local workflow folder**: You must run this command from your project directory. The CLI reads the workflow name and configuration from your `workflow.yaml` file to identify which workflow to delete. - **[Logged in](/cre/reference/cli/authentication#cre-login)**: Authenticated with the platform by running `cre login`. To check if you are logged in, run `cre whoami`. -- **A `deployment-registry` value**: Updated CLI-generated targets use `private` by default. For older workflow files, make sure the target has `deployment-registry: "private"` or `deployment-registry: "onchain:ethereum-mainnet"`. +- **(Optional) `deployment-registry` in `workflow.yaml`**: When omitted, the CLI uses the default onchain registry. Set to `"private"` to manage the workflow via the Chainlink-hosted private registry. See [Choosing your registry](/cre/guides/operations/deploying-workflows#choosing-your-registry). - **(Onchain registry only) A funded wallet**: The account must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction. ## Deleting a workflow @@ -9258,15 +9438,15 @@ Registries available to your organization ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet - Type: onchain + Type: on-chain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 Private (Chainlink-hosted) ID: private - Type: offchain + Type: off-chain ``` -The `ID` value is what you put in the required `user-workflow.deployment-registry` field of your `workflow.yaml` to target that registry on `cre workflow deploy`. See [Project Configuration](/cre/reference/project-configuration#3-2-workflow-configuration-workflow-yaml) and [Deploying Workflows](/cre/guides/operations/deploying-workflows#choosing-your-registry). +The `ID` value is what you put in the optional `user-workflow.deployment-registry` field of your `workflow.yaml` to target that registry on `cre workflow deploy`. See [Project Configuration](/cre/reference/project-configuration#3-2-workflow-configuration-workflow-yaml) and [Deploying Workflows](/cre/guides/operations/deploying-workflows#choosing-your-registry). If no registries are found for your environment, the command prints a warning and exits cleanly. @@ -10453,8 +10633,8 @@ Here are resources to help you go from simulation to production. Deploying requires Early Access approval. Run `cre account access` or visit app.chain.link/cre/request-access to submit a request. See [Requesting Deploy Access](/cre/account/deploy-access). While you wait, continue building and simulating workflows. -1. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. Set `deployment-registry` in `workflow.yaml` to choose private registry management or the public onchain Workflow Registry. -2. **(Optional) [Link a Wallet Key](/cre/organization/linking-keys)** — Only needed if you set `deployment-registry: "onchain:ethereum-mainnet"`. +1. **[Link a Wallet Key](/cre/organization/linking-keys)** — Required for the default onchain Workflow Registry. Not needed when using `deployment-registry: "private"`. +2. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live. Optionally set `deployment-registry: "private"` in `workflow.yaml` to use the Chainlink-hosted private registry (no linked key or gas required for registry operations). 3. **[Monitor Your Workflow](/cre/guides/operations/monitoring-workflows)** — Watch it execute and debug issues ### Explore different triggers @@ -10655,6 +10835,7 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera - **Language**: Select `Typescript` and press Enter. - **Pick a workflow template**: Use the arrow keys to select `Helloworld: Typescript Hello World example` and press Enter. We are starting from scratch to learn all the configuration steps. - **Workflow name**: my-calculator-workflow + - **Deployment registry**: Select your preferred registry. Private (off-chain) registries appear first — choose `private` for quick testing without a wallet or gas, or `onchain:ethereum-mainnet` for the public Workflow Registry. If no registries appear, this step is skipped. The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it. @@ -16188,14 +16369,15 @@ cre init [flags] **Flags:** -| Flag | Description | -| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | -| `--non-interactive` | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments). | -| `-p, --project-name` | Name for the new project (required for a new project when using `--non-interactive`). | -| `-t, --template` | Template name to use (for example `hello-world-ts`). Run `cre templates list` to see IDs and required networks. | -| `-w, --workflow-name` | Name for the new workflow. | -| `--refresh` | Bypass the template cache and fetch fresh data from GitHub. | -| `--rpc-url` | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. | +| Flag | Description | +| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `--non-interactive` | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments). | +| `-p, --project-name` | Name for the new project (required for a new project when using `--non-interactive`). | +| `-t, --template` | Template name to use (for example `hello-world-ts`). Run `cre templates list` to see IDs and required networks. | +| `-w, --workflow-name` | Name for the new workflow. | +| `--deployment-registry` | Registry ID to write into the generated `workflow.yaml` (e.g. `private` or `onchain:ethereum-mainnet`). Run `cre registry list` to see available IDs. In `--non-interactive` mode, omitting this flag prints a warning and defaults to on-chain. | +| `--refresh` | Bypass the template cache and fetch fresh data from GitHub. | +| `--rpc-url` | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. | Inherited [global flags](/cre/reference/cli#global-flags) include **`-R, --project-root`**, which `cre init` uses as the directory where the project is created when you pass it explicitly. @@ -16207,6 +16389,7 @@ Running `cre init` without flags starts an interactive setup that guides you thr 2. **Language** (Go or TypeScript) 3. **Workflow template** (fetched dynamically from configured template sources) 4. **Workflow name** +5. **Deployment registry** — select which registry the generated `workflow.yaml` targets. Private (off-chain) registries appear first with the cursor defaulted to them. If your organization has no registries configured, this step is skipped and the field is omitted from `workflow.yaml`.