diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts index 47a3e3c5b26..57d961200e5 100644 --- a/src/config/sidebar.ts +++ b/src/config/sidebar.ts @@ -449,6 +449,16 @@ export const SIDEBAR: Partial> = { { title: "Deploying Workflows", url: "cre/guides/operations/deploying-workflows", + children: [ + { + title: "Deploying to the Private Registry", + url: "cre/guides/operations/deploying-to-private-registry", + }, + { + title: "Deploying to the Onchain Registry", + url: "cre/guides/operations/deploying-to-onchain-registry", + }, + ], }, { title: "Activating & Pausing Workflows", 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..2114f1009f7 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. **[Link a Wallet Key](/cre/organization/linking-keys)** — Required for the default onchain Workflow Registry. Not needed when using `deployment-registry: "private"`. +1. **[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). 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..4cd184fff16 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. **[Link a Wallet Key](/cre/organization/linking-keys)** — Required for the default onchain Workflow Registry. Not needed when using `deployment-registry: "private"`. +1. **[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). 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..1a38f21bd69 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 `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -86,6 +86,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**: + - **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. 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..ac5442e4d4a 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 `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -86,6 +86,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**: + - **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. diff --git a/src/content/cre/guides/operations/activating-pausing-workflows.mdx b/src/content/cre/guides/operations/activating-pausing-workflows.mdx index 7d30817d2d0..1a34b472c13 100644 --- a/src/content/cre/guides/operations/activating-pausing-workflows.mdx +++ b/src/content/cre/guides/operations/activating-pausing-workflows.mdx @@ -10,7 +10,7 @@ metadata: import { Aside } from "@components" -After deploying a workflow, you can control its operational state using the `cre workflow activate` and `cre workflow pause` commands. These commands modify the workflow's status in the Workflow Registry contract, determining whether it can respond to triggers. +After deploying a workflow, you can control its operational state using the `cre workflow activate` and `cre workflow pause` commands. These commands modify the workflow's status in the registry selected by `deployment-registry`, determining whether it can respond to triggers. **Workflow states:** @@ -21,11 +21,12 @@ After deploying a workflow, you can control its operational state using the `cre Before activating or pausing workflows, ensure you have: -- **A [deployed workflow](/cre/guides/operations/deploying-workflows)**: You must have a workflow that has been successfully deployed to the Workflow Registry. -- **Workflow ownership**: You must be the owner of the workflow (the account that originally deployed it). Only the workflow owner can activate or pause it. +- **A [deployed workflow](/cre/guides/operations/deploying-workflows)**: You must have a workflow that has been successfully deployed to the registry selected by `deployment-registry`. +- **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 funded wallet**: The account you are using must be funded with ETH on Ethereum Mainnet to pay the gas fees for the onchain transaction to the Workflow Registry contract. +- **(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#comparing-registries). +- **(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 @@ -46,15 +47,16 @@ cre workflow activate my-workflow --target production-settings The CLI identifies which workflow to activate based on: - `workflow-name` from your `workflow.yaml` file -- `workflow-owner-address` (either from `workflow.yaml` or derived from your private key in `.env`) +- `deployment-registry` from your `workflow.yaml` file +- `workflow-owner-address` for onchain registry workflows, or your CRE organization for private registry workflows ### What happens during activation -1. The CLI fetches the workflow matching your workflow name and owner address +1. The CLI fetches the workflow matching your workflow name and configured registry authorization 1. It validates that the workflow is currently paused -1. If valid, it sends an onchain transaction to change the status to active +1. If valid, it updates the workflow status in the target's configured registry. For `onchain:ethereum-mainnet`, this sends an onchain transaction. For `private`, this updates the Chainlink-hosted private registry through your CRE login session. -### Example output +### Example onchain registry output ```bash > cre workflow activate my-workflow --target production-settings @@ -114,11 +116,11 @@ cre workflow pause my-workflow --target production-settings ### What happens during pausing -1. The CLI fetches the workflow matching your workflow name and owner address +1. The CLI fetches the workflow matching your workflow name and configured registry authorization 1. It validates that the workflow is currently active -1. If valid, it sends an onchain transaction to change the status to paused +1. If valid, it updates the workflow status in the target's configured registry. For `onchain:ethereum-mainnet`, this sends an onchain transaction. For `private`, this updates the Chainlink-hosted private registry through your CRE login session. -### Example output +### Example onchain registry output ```bash > cre workflow pause my-workflow --target production-settings @@ -162,7 +164,7 @@ Details: ## Using multi-sig wallets -Both `activate` and `pause` commands support multi-sig wallets through the `--unsigned` flag. When using this flag, the CLI generates raw transaction data that you can submit through your multi-sig wallet interface instead of sending the transaction directly. +For onchain registry workflows, both `activate` and `pause` commands support multi-sig wallets through the `--unsigned` flag. When using this flag, the CLI generates raw transaction data that you can submit through your multi-sig wallet interface instead of sending the transaction directly. Private registry workflows do not use `--unsigned` because they do not submit registry transactions. For complete setup instructions, configuration requirements, and step-by-step guidance, see [Using Multi-sig Wallets](/cre/guides/operations/using-multisig-wallets). diff --git a/src/content/cre/guides/operations/deleting-workflows.mdx b/src/content/cre/guides/operations/deleting-workflows.mdx index 826b3a69070..0832c40a011 100644 --- a/src/content/cre/guides/operations/deleting-workflows.mdx +++ b/src/content/cre/guides/operations/deleting-workflows.mdx @@ -3,24 +3,25 @@ section: cre date: Last Modified title: "Deleting Workflows" metadata: - description: "Remove workflows permanently: learn how to safely delete deployed workflows from the Workflow Registry when no longer needed." + description: "Remove workflows permanently: learn how to safely delete deployed workflows from their configured registry when no longer needed." datePublished: "2025-11-04" lastModified: "2025-11-04" --- import { Aside } from "@components" -Deleting a workflow permanently removes it from the Workflow Registry contract. This action cannot be undone, and the workflow will no longer be able to respond to triggers. +Deleting a workflow permanently removes it from the registry selected by `deployment-registry`. This action cannot be undone, and the workflow will no longer be able to respond to triggers. ## Prerequisites Before deleting a workflow, ensure you have: -- **A [deployed workflow](/cre/guides/operations/deploying-workflows)**: The workflow must exist in the Workflow Registry. -- **Workflow ownership**: You must be the owner of the workflow (the account that originally deployed it). Only the workflow owner can delete it. +- **A [deployed workflow](/cre/guides/operations/deploying-workflows)**: The workflow must exist in the registry selected by `deployment-registry`. +- **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 funded wallet**: The account must be funded with ETH on Ethereum Mainnet to pay the gas fees for the onchain transaction to the Workflow Registry contract. +- **(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#comparing-registries). +- **(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 @@ -33,21 +34,22 @@ cre workflow delete my-workflow --target production-settings The CLI identifies which workflow to delete based on: - `workflow-name` from your `workflow.yaml` file -- `workflow-owner-address` (either from `workflow.yaml` or derived from your private key in `.env`) +- `deployment-registry` from your `workflow.yaml` file +- `workflow-owner-address` for onchain registry workflows, or your CRE organization for private registry workflows ### What happens during deletion -1. The CLI fetches all workflows matching your workflow name and owner address +1. The CLI fetches all workflows matching your workflow name and configured registry authorization 1. It displays details about the workflow(s) to be deleted 1. It prompts you to confirm by typing the workflow name -1. Once confirmed, it sends an onchain transaction to delete the workflow from the Workflow Registry +1. Once confirmed, it deletes the workflow from the target's configured registry. For `onchain:ethereum-mainnet`, this sends an onchain transaction. For `private`, this updates the Chainlink-hosted private registry through your CRE login session. {/* prettier-ignore */} -### Example output +### Example onchain registry output ```bash > cre workflow delete my-workflow --target production-settings @@ -105,7 +107,7 @@ cre workflow delete my-workflow --yes --target production-settings ## Using multi-sig wallets -The `delete` command supports multi-sig wallets through the `--unsigned` flag. When using this flag, the CLI generates raw transaction data that you can submit through your multi-sig wallet interface instead of sending the transaction directly. +For onchain registry workflows, the `delete` command supports multi-sig wallets through the `--unsigned` flag. When using this flag, the CLI generates raw transaction data that you can submit through your multi-sig wallet interface instead of sending the transaction directly. Private registry workflows do not use `--unsigned` because they do not submit registry transactions. For complete setup instructions, configuration requirements, and step-by-step guidance, see [Using Multi-sig Wallets](/cre/guides/operations/using-multisig-wallets). diff --git a/src/content/cre/guides/operations/deploying-to-onchain-registry.mdx b/src/content/cre/guides/operations/deploying-to-onchain-registry.mdx new file mode 100644 index 00000000000..4a5f89075e4 --- /dev/null +++ b/src/content/cre/guides/operations/deploying-to-onchain-registry.mdx @@ -0,0 +1,265 @@ +--- +section: cre +date: Last Modified +title: "Deploying to the Onchain Registry" +metadata: + description: "Deploy CRE workflows to the public Workflow Registry contract on Ethereum Mainnet using a linked wallet key." + datePublished: "2026-05-06" + lastModified: "2026-05-06" +--- + +import { Aside } from "@components" + +{/* prettier-ignore */} + + +The **public onchain registry** is the Workflow Registry contract on Ethereum Mainnet. Deploying to it records your workflow onchain — your linked wallet address becomes the workflow owner and every lifecycle operation (deploy, activate, pause, update, delete) submits a transaction to that contract. + +For a lower-friction alternative that requires no wallet or gas for registry management, see [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry). + +## Prerequisites + +Before deploying to the onchain registry, ensure you have: + +- **Early Access approval**: 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/organization/linking-keys)**: Linked your EOA or multi-sig wallet to your CRE organization by running `cre account link-key`. See [Linking Wallet Keys](/cre/organization/linking-keys) for instructions. +- **A funded wallet**: The account you are deploying from must hold ETH on Ethereum Mainnet to pay gas for the registration transaction. +- **`CRE_ETH_PRIVATE_KEY` in your `.env`**: Your wallet's private key, used by the CLI to sign registry transactions. +- **An Ethereum Mainnet RPC URL in `project.yaml`**: Required for the CLI to submit transactions. Example: `https://ethereum-rpc.publicnode.com`. +- **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). + +## The deployment process + +The `cre workflow deploy` command handles the entire end-to-end process: + +1. **Compiles** your workflow to a WASM binary. +1. **Uploads** the compiled binary and any associated configuration files 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`. The transaction contains the workflow's name, owner, and artifact URLs. + +{/* prettier-ignore */} + + +### Step 1: Ensure your configuration is correct + +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. + +When you run `cre init`, the wizard prompts you to select a deployment registry after entering your workflow name. Selecting `onchain:ethereum-mainnet` writes `deployment-registry: "onchain:ethereum-mainnet"` into the generated `workflow.yaml` automatically. If you chose the onchain registry during init, your config is already set. + +If you initialized without selecting a registry, or are adding a new target, add `deployment-registry: "onchain:ethereum-mainnet"` explicitly. The field is optional — when omitted the CLI defaults to onchain — but setting it is recommended to make the intent clear. + +```yaml +# workflow.yaml +production-settings: + user-workflow: + workflow-name: "my-workflow-production" + deployment-registry: "onchain:ethereum-mainnet" + workflow-artifacts: + workflow-path: "./main.ts" # Go: "." + config-path: "./config.production.json" + secrets-path: "" +``` + +If you are deploying from a **multi-sig wallet**, specify your multi-sig address in the `workflow-owner-address` field. If deploying from a standard EOA, leave this field out — the owner is automatically derived from `CRE_ETH_PRIVATE_KEY` in your `.env` file. + +For more details on configuration, see the [Project Configuration](/cre/reference/project-configuration) reference. + +### Step 2: Run the deploy command + +**From your project root directory**, run the `deploy` command with the path to your workflow folder: + +```bash +cre workflow deploy [flags] +``` + +Example command targeting the `production-settings` environment: + +```bash +cre workflow deploy my-workflow --target production-settings +``` + +**Available flags:** + +| Flag | Description | +| ---------------- | --------------------------------------------------------------------------------------- | +| `--target` | Sets the target environment from your configuration files (e.g., `production-settings`) | +| `--output` | The output file for the compiled WASM binary (default: `"./binary.wasm.br.b64"`) | +| `--wasm` | Path to a pre-built WASM binary (skips compilation). Useful in CI/CD pipelines | +| `--config` | Override the config file path from `workflow.yaml` | +| `--no-config` | Deploy without a config file | +| `--unsigned` | Return the raw transaction instead of broadcasting it (for multi-sig wallets) | +| `--yes` | Skip confirmation prompts and proceed with the operation | +| `--project-root` | Path to the project root directory | +| `--env` | Path to your `.env` file (default: `".env"`) | +| `--verbose` | Enable verbose logging to print `DEBUG` level logs | + +### Step 3: Monitor the output + +The CLI provides detailed logs of the compilation, upload, and the onchain registration transaction: + +```bash +> cre workflow deploy my-workflow --target production-settings + +Deploying Workflow : my-workflow +Target : production-settings +Owner Address : + +Compiling workflow... +Workflow compiled successfully + +Verifying ownership... +Workflow owner link status: owner=, linked=true +Key ownership verified + +Uploading files... +✔ Loaded binary from: ./binary.wasm.br.b64 +✔ Uploaded binary to: https://storage.cre.example.com/artifacts//binary.wasm +✔ Loaded config from: ./config.json +✔ Uploaded config to: https://storage.cre.example.com/artifacts//config + +Preparing deployment transaction... +Preparing transaction for workflowID: +Transaction details: + Chain Name: ethereum-mainnet + To: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 + Function: UpsertWorkflow + Inputs: + [0]: my-workflow + [1]: my-workflow + [2]: + [3]: 0 + [4]: zone-a + [5]: https://storage.cre.example.com/artifacts//binary.wasm + [6]: https://storage.cre.example.com/artifacts//config + [7]: 0x + [8]: false + Data: b377bfc50000000000000000000000000000000000... +Estimated Cost: + Gas Price: 0.00100001 gwei + Total Cost: 0.00000079 ETH +? Do you want to execute this transaction?: + ▸ Yes + No + +Transaction confirmed +View on explorer: https://etherscan.io/tx/0x58599f6...d916b + +✓ Workflow deployed successfully + +Details: + Registry: onchain:ethereum-mainnet + Contract address: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 + Transaction hash: 0x58599f6...d916b + Workflow Name: my-workflow + Workflow ID: + Binary URL: https://storage.cre.example.com/artifacts//binary.wasm + Config URL: https://storage.cre.example.com/artifacts//config +``` + +## Verifying your deployment + +After a successful deployment, verify your workflow was registered correctly: + +1. **CLI**: Run [`cre workflow list`](/cre/reference/cli/workflow#cre-workflow-list) to see every workflow registered to your organization and its current status. + +1. **CRE UI**: View your deployed workflow in the [CRE platform](https://app.chain.link/cre/discover). Navigate to the **Workflows** section to see the workflow's status, ID, and execution history. + +1. **Block Explorer**: The CLI output includes the transaction hash. The `WorkflowRegistry` contract is deployed on **Ethereum Mainnet** at `0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5`. + +## CI/CD pipeline integration + +The `cre workflow build` and `cre workflow deploy` commands can run as independent steps, making it straightforward to integrate CRE deployments into CI/CD pipelines. + +The separation gives you two key benefits: + +- **Build once, deploy many times** — Compile your workflow to a WASM binary in a build step, then promote that exact binary to staging and production without recompiling. This ensures the artifact you tested is the artifact you deploy. +- **Verify before deploying** — Use `cre workflow hash` after building to record and verify content hashes before submitting a deployment transaction. + +### Example: GitHub Actions + +The following example shows a two-job pipeline: a `build` job that compiles and uploads the WASM artifact, and a `deploy` job that downloads and deploys that exact binary. + +```yaml +# .github/workflows/deploy.yml +name: Deploy Workflow + +on: + push: + branches: [main] + +jobs: + build: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Install CRE CLI + run: curl -sSL https://github.com/smartcontractkit/cre-cli/releases/latest/download/install.sh | sh + + - name: Build workflow + run: cre workflow build ./my-workflow --output ./my-workflow/binary.wasm --non-interactive + env: + CRE_API_KEY: ${{ secrets.CRE_API_KEY }} + + - name: Display content hashes + run: cre workflow hash ./my-workflow --wasm ./my-workflow/binary.wasm --target production-settings --non-interactive + env: + CRE_API_KEY: ${{ secrets.CRE_API_KEY }} + CRE_ETH_PRIVATE_KEY: ${{ secrets.CRE_ETH_PRIVATE_KEY }} + + - name: Upload artifact + uses: actions/upload-artifact@v4 + with: + name: workflow-binary + path: ./my-workflow/binary.wasm + + deploy: + needs: build + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Install CRE CLI + run: curl -sSL https://github.com/smartcontractkit/cre-cli/releases/latest/download/install.sh | sh + + - name: Download artifact + uses: actions/download-artifact@v4 + with: + name: workflow-binary + path: ./my-workflow + + - name: Deploy workflow + run: cre workflow deploy ./my-workflow --wasm ./my-workflow/binary.wasm --target production-settings --yes --non-interactive + env: + CRE_API_KEY: ${{ secrets.CRE_API_KEY }} + CRE_ETH_PRIVATE_KEY: ${{ secrets.CRE_ETH_PRIVATE_KEY }} + INFURA_API_KEY: ${{ secrets.INFURA_API_KEY }} +``` + +{/* prettier-ignore */} + + +{/* prettier-ignore */} + + +## Using multi-sig wallets + +The `deploy` command supports multi-sig wallets through the `--unsigned` flag. When using this flag, the CLI generates raw transaction data that you can submit through your multi-sig wallet interface instead of sending the transaction directly. + +For complete setup instructions, configuration requirements, and step-by-step guidance, see [Using Multi-sig Wallets](/cre/guides/operations/using-multisig-wallets). + +## Next steps + +- [Deploying Workflows](/cre/guides/operations/deploying-workflows) — Registry overview and comparison +- [Activating & Pausing Workflows](/cre/guides/operations/activating-pausing-workflows) — Control workflow execution state +- [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 +- [Using Multi-sig Wallets](/cre/guides/operations/using-multisig-wallets) — Multi-sig wallet setup and transaction signing diff --git a/src/content/cre/guides/operations/deploying-to-private-registry.mdx b/src/content/cre/guides/operations/deploying-to-private-registry.mdx new file mode 100644 index 00000000000..0d4693d7853 --- /dev/null +++ b/src/content/cre/guides/operations/deploying-to-private-registry.mdx @@ -0,0 +1,268 @@ +--- +section: cre +date: Last Modified +title: "Deploying to the Private Registry" +metadata: + description: "Deploy and manage CRE workflows using the Chainlink-hosted private registry — no linked wallet, no gas, and no Ethereum Mainnet RPC required for registry operations." + datePublished: "2026-05-06" + lastModified: "2026-05-06" +--- + +import { Aside } from "@components" + +{/* prettier-ignore */} + + +The **private registry** is a Chainlink-hosted, offchain workflow registry. 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. + +This is the default registry for new projects initialized with `cre init`. For a comparison of both registry options, see [Deploying Workflows](/cre/guides/operations/deploying-workflows). + +{/* prettier-ignore */} + + +## 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. If no private registry appears, contact your Chainlink account team. 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: Set `deployment-registry` in your `workflow.yaml` + +When you run `cre init`, the wizard prompts you to select a deployment registry after entering your workflow name. Private (off-chain) registries appear first with the cursor pre-selected on them. Selecting `private` writes `deployment-registry: "private"` into both targets of the generated `workflow.yaml` automatically — you can skip the manual step below. + +If you skipped the step, used `--non-interactive` without `--deployment-registry`, or are adding a new target to an existing project, add `deployment-registry: "private"` under the `user-workflow` section manually: + +**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: "" +``` + +{/* prettier-ignore */} + + +## Step 2: 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 3: 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. + +{/* prettier-ignore */} + + +## 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 }} +``` + +{/* prettier-ignore */} + + +## Next steps + +- [Deploying Workflows](/cre/guides/operations/deploying-workflows) — Registry overview and comparison +- [Deploying to the Onchain Registry](/cre/guides/operations/deploying-to-onchain-registry) — Deploy with a linked wallet key and onchain record +- [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 diff --git a/src/content/cre/guides/operations/deploying-workflows.mdx b/src/content/cre/guides/operations/deploying-workflows.mdx index 8c1b863bc25..97ae6b073be 100644 --- a/src/content/cre/guides/operations/deploying-workflows.mdx +++ b/src/content/cre/guides/operations/deploying-workflows.mdx @@ -3,9 +3,9 @@ section: cre date: Last Modified title: "Deploying Workflows" metadata: - description: "Deploy your workflow: learn how to register your workflow and start running it across a Decentralized Oracle Network (DON)." + description: "Deploy your workflow: understand the two CRE registry models and choose the right deployment path for your project." datePublished: "2025-11-04" - lastModified: "2026-04-30" + lastModified: "2026-05-06" --- import { Aside } from "@components" @@ -18,226 +18,69 @@ 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). +When you deploy a workflow, you 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, selected per deployment target via `deployment-registry` in `workflow.yaml`: -## Prerequisites +- **Private workflow**: Lifecycle operations (deploy, activate, pause, update, delete) are authorized by your CRE login session against the Chainlink-hosted private registry. No linked wallet, no gas, no Ethereum Mainnet RPC required for registry management. This is the default for new projects initialized with `cre init`. +- **Public/onchain workflow**: Lifecycle operations submit transactions to the Workflow Registry contract on Ethereum Mainnet, authorized by your linked web3 wallet key. -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. - -## The deployment process - -The `cre workflow deploy` command handles the entire end-to-end process for you: - -1. **Compiles** your workflow to a WASM binary. -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. +This is a **control-plane** choice — it governs how workflow management is authorized, not how workflow execution behaves. See [Private workflow](/cre/key-terms#private-workflow) and [Confidential execution](/cre/key-terms#confidential-workflow-or-confidential-execution) for the distinction. {/* prettier-ignore */} - -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:** @@ -8987,10 +9415,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:** @@ -9013,7 +9441,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:** @@ -9027,10 +9455,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:** @@ -9333,7 +9761,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. @@ -9349,7 +9782,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:** @@ -9366,8 +9799,14 @@ ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet Type: on-chain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 + +Private (Chainlink-hosted) + ID: private + Type: off-chain ``` +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#comparing-registries). + If no registries are found for your environment, the command prints a warning and exits cleanly. ## Learn more @@ -9389,6 +9828,15 @@ Last Updated: 2026-04-10 The `cre secrets` commands manage secrets stored in the Vault DON (Decentralized Oracle Network) for deployed workflows. These commands allow you to create, update, delete, and list secrets that your workflows can access at runtime. +## Auth modes + +`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.** 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. + ## Authorization flow Secrets operations use your **workflow owner address** to authorize Vault DON access: @@ -9427,8 +9875,8 @@ Secrets are organized into **namespaces**, which act as logical groupings (e.g., @@ -9453,10 +9901,11 @@ cre secrets create [SECRETS_FILE_PATH] [flags] ### Flags -| Flag | Type | Default | Description | -| ------------ | -------- | ------- | --------------------------------------------------------------- | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Input file format @@ -9516,10 +9965,11 @@ cre secrets update [SECRETS_FILE_PATH] [flags] ### Flags -| Flag | Type | Default | Description | -| ------------ | -------- | ------- | --------------------------------------------------------------- | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Input file format @@ -9560,10 +10010,11 @@ cre secrets delete [SECRETS_FILE_PATH] [flags] ### Flags -| Flag | Type | Default | Description | -| ------------ | -------- | ------- | --------------------------------------------------------------- | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Input file format @@ -9603,11 +10054,12 @@ cre secrets list [flags] ### Flags -| Flag | Type | Default | Description | -| ------------- | -------- | -------- | --------------------------------------------------------------- | -| `--namespace` | string | `"main"` | Namespace to list secrets from | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--namespace` | string | `"main"` | Namespace to list secrets from | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Example @@ -10260,8 +10712,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 -2. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live +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 @@ -10410,7 +10862,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 `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -10462,6 +10914,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. @@ -15961,14 +16414,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. @@ -15980,6 +16434,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. @@ -4058,7 +4098,24 @@ Before managing secrets for deployed workflows, ensure you have: 1. **CRE CLI installed**: See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) 2. **Authentication**: You must be logged in with `cre login` -3. **Owner address configured**: Your `workflow-owner-address` must be set in your project configuration +3. **(Web3-keyed flow only) Owner address configured**: When managing secrets owned by a workflow owner address (the onchain registry flow), your `workflow-owner-address` must be set. Browser-auth flows on the private registry use your CRE login session and don't require this. + +## Auth modes: web3 key vs. browser auth + +`cre secrets` supports two ways to authorize Vault operations, mirroring the [private vs. public workflow management split](/cre/guides/operations/deploying-workflows#private-vs-public-workflow-management) used for workflow deployment: + +- **Web3-keyed.** Each operation submits an onchain authorization tied to your linked workflow owner address (`workflow-owner-address`). Use this when your workflow is deployed to the onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`). +- **Browser auth (`--secrets-auth=browser`).** The CLI opens a browser-based OAuth (PKCE) flow against the Vault DON gateway and authorizes the operation against your CRE organization. No wallet, no gas, no `workflow-owner-address` needed. Use this when your workflow is deployed to the `private` registry, or when your team manages secrets at the organization level rather than per-wallet. + +You can specify the mode per command with `--secrets-auth`. If omitted, the CLI uses the default for your target. + +```bash +# Web3-keyed (onchain registry) +cre secrets create production-secrets.yaml --target production-settings + +# Browser auth (private registry / org-owned) +cre secrets create production-secrets.yaml --target staging-settings --secrets-auth=browser +``` ## How secrets work with deployed workflows @@ -4861,7 +4918,7 @@ If your workflow requires higher limits than the defaults, you can request a lim # Deploying Workflows Source: https://docs.chain.link/cre/guides/operations/deploying-workflows -Last Updated: 2026-04-30 +Last Updated: 2026-05-06 -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 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, selected per deployment target via `deployment-registry` in `workflow.yaml`: + +- **Private workflow**: Lifecycle operations (deploy, activate, pause, update, delete) are authorized by your CRE login session against the Chainlink-hosted private registry. No linked wallet, no gas, no Ethereum Mainnet RPC required for registry management. This is the default for new projects initialized with `cre init`. +- **Public/onchain workflow**: Lifecycle operations submit transactions to the Workflow Registry contract on Ethereum Mainnet, authorized by your linked web3 wallet key. + +This is a **control-plane** choice — it governs how workflow management is authorized, not how workflow execution behaves. See [Private workflow](/cre/key-terms#private-workflow) and [Confidential execution](/cre/key-terms#confidential-workflow-or-confidential-execution) for the distinction. + + + + +## Comparing registries + +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 `deployment-registry` in your `workflow.yaml`. + +| | Private workflow | Public / onchain workflow | +| ------------------------------- | ------------------------------- | ---------------------------------- | +| `deployment-registry` value | `"private"` | `"onchain:ethereum-mainnet"` | +| Authorization | CRE login session | Linked web3 wallet key | +| Ethereum Mainnet RPC required | No | Yes | +| ETH for gas (registry ops) | No | Yes | +| `cre account link-key` required | No | Yes | +| Creates onchain record | No | Yes, in Workflow Registry contract | +| Default for `cre init` projects | Yes | No | +| Ideal for | Testing, team-managed workflows | Production, multisig ownership | + +Secrets follow the same split. See [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed) for the per-registry secrets flows. + +## Limits + +Both registry types have per-organization defaults. See [Service Quotas](/cre/service-quotas#registry-quotas) for current values. + +| | Default limit | +| ------------------------------------------- | ------------- | +| Private registry workflows per organization | 3 | +| Linked keys per organization (onchain) | 1 | +| Workflows per linked key (onchain) | 3 | + +## Deployment guides + +For step-by-step instructions, choose the guide for your target registry: + +- **[Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry)** — Uses your CRE login session. No wallet, no gas, no Ethereum Mainnet RPC required for registry operations. +- **[Deploying to the Onchain Registry](/cre/guides/operations/deploying-to-onchain-registry)** — Requires a linked wallet key and ETH on Ethereum Mainnet for registry transaction gas. + +--- + +# 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. 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. + +This is the default registry for new projects initialized with `cre init`. For a comparison of both registry options, see [Deploying Workflows](/cre/guides/operations/deploying-workflows). + + + ## Prerequisites -Before you can deploy a workflow, you must have: +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. If no private registry appears, contact your Chainlink account team. 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: Set `deployment-registry` in your `workflow.yaml` + +When you run `cre init`, the wizard prompts you to select a deployment registry after entering your workflow name. Private (off-chain) registries appear first with the cursor pre-selected on them. Selecting `private` writes `deployment-registry: "private"` into both targets of the generated `workflow.yaml` automatically — you can skip the manual step below. + +If you skipped the step, used `--non-interactive` without `--deployment-registry`, or are adding a new target to an existing project, add `deployment-registry: "private"` under the `user-workflow` section manually: + +**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: "" +``` + + + + +## Step 2: 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 3: Verify the deployment + +Run `cre workflow list` to confirm the workflow appears and is registered to the private registry: + +```bash +cre workflow list +``` -- **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). +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) — Registry overview and comparison +- [Deploying to the Onchain Registry](/cre/guides/operations/deploying-to-onchain-registry) — Deploy with a linked wallet key and onchain record +- [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 + +--- + +# Deploying to the Onchain Registry +Source: https://docs.chain.link/cre/guides/operations/deploying-to-onchain-registry +Last Updated: 2026-05-06 + + + +The **public onchain registry** is the Workflow Registry contract on Ethereum Mainnet. Deploying to it records your workflow onchain — your linked wallet address becomes the workflow owner and every lifecycle operation (deploy, activate, pause, update, delete) submits a transaction to that contract. + +For a lower-friction alternative that requires no wallet or gas for registry management, see [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry). + +## Prerequisites + +Before deploying to the onchain registry, ensure you have: + +- **Early Access approval**: 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. +- **[Linked your key](/cre/organization/linking-keys)**: Linked your EOA or multi-sig wallet to your CRE organization by running `cre account link-key`. See [Linking Wallet Keys](/cre/organization/linking-keys) for instructions. +- **A funded wallet**: The account you are deploying from must hold ETH on Ethereum Mainnet to pay gas for the registration transaction. +- **`CRE_ETH_PRIVATE_KEY` in your `.env`**: Your wallet's private key, used by the CLI to sign registry transactions. +- **An Ethereum Mainnet RPC URL in `project.yaml`**: Required for the CLI to submit transactions. Example: `https://ethereum-rpc.publicnode.com`. +- **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). ## The deployment process -The `cre workflow deploy` command handles the entire end-to-end process for you: +The `cre workflow deploy` command handles the entire end-to-end process: 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. +2. **Uploads** the compiled binary and any associated configuration files 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`. The transaction contains the workflow's name, owner, and artifact URLs. -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:** @@ -8565,10 +8993,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:** @@ -8586,7 +9014,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:** @@ -8600,10 +9028,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:** @@ -8626,7 +9054,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:** @@ -8640,10 +9068,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:** @@ -8946,7 +9374,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. @@ -8962,7 +9395,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:** @@ -8979,8 +9412,14 @@ ethereum-mainnet (0x4Ac5...E7e5) ID: onchain:ethereum-mainnet Type: on-chain Addr: 0x4Ac54353FA4Fa961AfcC5ec4B118596d3305E7e5 + +Private (Chainlink-hosted) + ID: private + Type: off-chain ``` +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#comparing-registries). + If no registries are found for your environment, the command prints a warning and exits cleanly. ## Learn more @@ -9002,6 +9441,15 @@ Last Updated: 2026-04-10 The `cre secrets` commands manage secrets stored in the Vault DON (Decentralized Oracle Network) for deployed workflows. These commands allow you to create, update, delete, and list secrets that your workflows can access at runtime. +## Auth modes + +`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.** 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. + ## Authorization flow Secrets operations use your **workflow owner address** to authorize Vault DON access: @@ -9040,8 +9488,8 @@ Secrets are organized into **namespaces**, which act as logical groupings (e.g., @@ -9066,10 +9514,11 @@ cre secrets create [SECRETS_FILE_PATH] [flags] ### Flags -| Flag | Type | Default | Description | -| ------------ | -------- | ------- | --------------------------------------------------------------- | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Input file format @@ -9129,10 +9578,11 @@ cre secrets update [SECRETS_FILE_PATH] [flags] ### Flags -| Flag | Type | Default | Description | -| ------------ | -------- | ------- | --------------------------------------------------------------- | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Input file format @@ -9173,10 +9623,11 @@ cre secrets delete [SECRETS_FILE_PATH] [flags] ### Flags -| Flag | Type | Default | Description | -| ------------ | -------- | ------- | --------------------------------------------------------------- | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Input file format @@ -9216,11 +9667,12 @@ cre secrets list [flags] ### Flags -| Flag | Type | Default | Description | -| ------------- | -------- | -------- | --------------------------------------------------------------- | -| `--namespace` | string | `"main"` | Namespace to list secrets from | -| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | -| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| Flag | Type | Default | Description | +| ---------------- | -------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `--namespace` | string | `"main"` | Namespace to list secrets from | +| `--timeout` | duration | `48h` | Timeout for the operation (e.g., `30m`, `2h`, `48h`). Max: `7d` | +| `--unsigned` | boolean | `false` | Generate raw transaction data for multi-sig wallets | +| `--secrets-auth` | string | *auto* | Authorization mode. Set to `browser` to authorize via browser-based OAuth (PKCE) using your CRE login session. See [Auth modes](#auth-modes). | ### Example @@ -10153,8 +10605,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 -2. **[Deploy Your Workflow](/cre/guides/operations/deploying-workflows)** — Push your workflow live +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 @@ -10303,7 +10755,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 `private` registry. Go to faucets.chain.link to get some Sepolia ETH. ## Step 1: Verify your authentication @@ -10355,6 +10807,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. @@ -15888,14 +16341,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. @@ -15907,6 +16361,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`. -Deletes a workflow from the Workflow Registry. +Deletes a workflow from the registry selected by `deployment-registry`. **Usage:** @@ -295,10 +295,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 b9c93a88de1..58dee5e4139 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`. @@ -136,6 +136,7 @@ Variable values are resolved from environment variables at runtime. This works a staging-settings: user-workflow: workflow-name: "my-por-workflow-staging" + # deployment-registry: "private" # Optional (new in v1.14.0). Omit to use the default onchain registry. workflow-artifacts: workflow-path: "." # Points to the workflow directory config-path: "./config.staging.json" @@ -145,6 +146,7 @@ production-settings: user-workflow: workflow-owner-address: "
" # Optional: For multi-sig wallets workflow-name: "my-por-workflow-production" + # deployment-registry: "onchain:ethereum-mainnet" # Explicit onchain registry (also the default when omitted). workflow-artifacts: workflow-path: "." # Points to the workflow directory config-path: "./config.production.json" @@ -153,17 +155,20 @@ 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 | New in v1.14.0. Selects which registry receives this target's deployment. When omitted, the CLI defaults to the public onchain Workflow Registry (same behavior as before v1.14.0). Set to `"private"` for Chainlink-hosted private registry management via your CRE login session (no linked key or gas required for registry operations). Set to `"onchain:ethereum-mainnet"` to explicitly target the public onchain Workflow Registry. Run [`cre registry list`](/cre/reference/cli/registry) to see registries available to your organization. | +| `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. | ### 3.3. Secrets configuration (`secrets.yaml`) diff --git a/src/content/cre/reference/project-configuration-ts.mdx b/src/content/cre/reference/project-configuration-ts.mdx index 024ffe1765b..f01c83488eb 100644 --- a/src/content/cre/reference/project-configuration-ts.mdx +++ b/src/content/cre/reference/project-configuration-ts.mdx @@ -53,7 +53,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/ @@ -61,14 +61,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. @@ -141,6 +141,7 @@ Variable values are resolved from environment variables at runtime. This works a staging-settings: user-workflow: workflow-name: "my-por-workflow-staging" + # deployment-registry: "private" # Optional (new in v1.14.0). Omit to use the default onchain registry. workflow-artifacts: workflow-path: "./main.ts" # Points to the TypeScript entry file config-path: "./config.staging.json" @@ -150,6 +151,7 @@ production-settings: user-workflow: workflow-owner-address: "
" # Optional: For multi-sig wallets workflow-name: "my-por-workflow-production" + # deployment-registry: "onchain:ethereum-mainnet" # Explicit onchain registry (also the default when omitted). workflow-artifacts: workflow-path: "./main.ts" # Points to the TypeScript entry file config-path: "./config.production.json" @@ -158,17 +160,20 @@ 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 | New in v1.14.0. Selects which registry receives this target's deployment. When omitted, the CLI defaults to the public onchain Workflow Registry (same behavior as before v1.14.0). Set to `"private"` for Chainlink-hosted private registry management via your CRE login session (no linked key or gas required for registry operations). Set to `"onchain:ethereum-mainnet"` to explicitly target the public onchain Workflow Registry. Run [`cre registry list`](/cre/reference/cli/registry) to see registries available to your organization. | +| `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. | +## 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 | + +{/* prettier-ignore */} + + ## Per-owner quotas These quotas apply to each workflow owner (user account) within an organization.