diff --git a/public/changelog.json b/public/changelog.json index 070944a4e54..9d08decc3d6 100644 --- a/public/changelog.json +++ b/public/changelog.json @@ -719,6 +719,13 @@ "title": "CCIP deprecated on Blast Mainnet", "topic": "CCIP" }, + { + "category": "release", + "date": "2026-05-14", + "description": "CRE CLI version 1.15.0 is now available. This release upgrades `cre workflow supported-chains` to show tenant-specific chains and their mock forwarder addresses (requires `cre login` or `CRE_API_KEY`), adds ADI testnet and Celo Sepolia support, and introduces a global `--allow-unknown-chains` flag to skip chain validation for experimental networks during simulation and deploy. `cre workflow hash` now auto-derives the workflow owner based on your target registry — on-chain uses `CRE_ETH_PRIVATE_KEY` or `workflow-owner-address`, off-chain uses the owner from your login session. The release also includes private registry bug fixes.\n\nUpdate your CLI by running `cre update` when prompted, or follow the [CLI Installation guide](https://docs.chain.link/cre/getting-started/cli-installation) for fresh installations.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.14.0...v1.15.0)", + "title": "CRE CLI v1.15.0 — Tenant-Scoped Chains and Chain Expansion", + "topic": "CRE" + }, { "category": "release", "date": "2026-05-08", diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts index 8ad535225ed..9a8c7904100 100644 --- a/src/config/sidebar.ts +++ b/src/config/sidebar.ts @@ -449,6 +449,24 @@ 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", + highlightAsCurrent: [ + "cre/guides/operations/deploying-to-private-registry-ts", + "cre/guides/operations/deploying-to-private-registry-go", + ], + }, + { + title: "Deploying to the Onchain Registry", + url: "cre/guides/operations/deploying-to-onchain-registry", + highlightAsCurrent: [ + "cre/guides/operations/deploying-to-onchain-registry-ts", + "cre/guides/operations/deploying-to-onchain-registry-go", + ], + }, + ], }, { 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-go.mdx b/src/content/cre/guides/operations/deploying-to-onchain-registry-go.mdx new file mode 100644 index 00000000000..c6c37701d1f --- /dev/null +++ b/src/content/cre/guides/operations/deploying-to-onchain-registry-go.mdx @@ -0,0 +1,272 @@ +--- +section: cre +date: Last Modified +title: "Deploying to the Onchain Registry" +sdkLang: "go" +pageId: "operations-deploying-to-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-12" +--- + +import { Aside } from "@components" + +{/* prettier-ignore */} + + +{/* 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 (Go)](/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: "." + 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-onchain-registry-ts.mdx b/src/content/cre/guides/operations/deploying-to-onchain-registry-ts.mdx new file mode 100644 index 00000000000..6d366110a50 --- /dev/null +++ b/src/content/cre/guides/operations/deploying-to-onchain-registry-ts.mdx @@ -0,0 +1,272 @@ +--- +section: cre +date: Last Modified +title: "Deploying to the Onchain Registry" +sdkLang: "ts" +pageId: "operations-deploying-to-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-12" +--- + +import { Aside } from "@components" + +{/* prettier-ignore */} + + +{/* 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 (TypeScript)](/cre/getting-started/part-1-project-setup-ts). + +## 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" + 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-go.mdx b/src/content/cre/guides/operations/deploying-to-private-registry-go.mdx new file mode 100644 index 00000000000..8766d2d4707 --- /dev/null +++ b/src/content/cre/guides/operations/deploying-to-private-registry-go.mdx @@ -0,0 +1,286 @@ +--- +section: cre +date: Last Modified +title: "Deploying to the Private Registry" +sdkLang: "go" +pageId: "operations-deploying-to-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-14" +--- + +import { Aside } from "@components" + +{/* prettier-ignore */} + + +{/* 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.15.0 or later**: Run `cre version` to check. See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) to install or update. +- **[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. + +Once you're logged in with **`cre login`**, run **`cre whoami`**. **`Deploy Access`** appears under **Account details**. Pending approval typically shows **`Deploy Access: Not enabled`**: + +```text +Deploy Access: Not enabled +``` + +After your organization has access—what you want before **`cre workflow deploy`**—you'll see **`Deploy Access: Enabled`**: + +```text +Deploy Access: Enabled +``` + +For how to submit a deploy access request, see [Requesting Deploy Access](/cre/account/deploy-access). + +- **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 (Go)](/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: + +```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. + +## HTTP triggers with the private registry + +If your private registry workflow uses an HTTP trigger, note that the gateway endpoint is different from the public registry: + +| Registry | HTTP trigger gateway URL | +| ---------------- | ------------------------------------------------------ | +| Public (onchain) | `https://01.gateway.zone-a.cre.chain.link` | +| **Private** | `https://01.enterprise-gateway.zone-a.cre.chain.link/` | + +Update your `GATEWAY_URL` (or equivalent configuration) wherever you send trigger requests — in local testing, CI scripts, or backend integrations — to use the enterprise gateway URL when targeting private registry workflows. + +See [Triggering Deployed Workflows](/cre/guides/workflow/using-triggers/http-trigger/triggering-deployed-workflows) for the full HTTP trigger request format and authentication details. + +## 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-to-private-registry-ts.mdx b/src/content/cre/guides/operations/deploying-to-private-registry-ts.mdx new file mode 100644 index 00000000000..71fd5fa83e4 --- /dev/null +++ b/src/content/cre/guides/operations/deploying-to-private-registry-ts.mdx @@ -0,0 +1,286 @@ +--- +section: cre +date: Last Modified +title: "Deploying to the Private Registry" +sdkLang: "ts" +pageId: "operations-deploying-to-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-14" +--- + +import { Aside } from "@components" + +{/* prettier-ignore */} + + +{/* 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.15.0 or later**: Run `cre version` to check. See the [Installation Guide](/cre/getting-started/cli-installation/macos-linux) to install or update. +- **[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. + +Once you're logged in with **`cre login`**, run **`cre whoami`**. **`Deploy Access`** appears under **Account details**. Pending approval typically shows **`Deploy Access: Not enabled`**: + +```text +Deploy Access: Not enabled +``` + +After your organization has access—what you want before **`cre workflow deploy`**—you'll see **`Deploy Access: Enabled`**: + +```text +Deploy Access: Enabled +``` + +For how to submit a deploy access request, see [Requesting Deploy Access](/cre/account/deploy-access). + +- **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 (TypeScript)](/cre/getting-started/part-1-project-setup-ts). + +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: + +```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: "" +``` + +{/* 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. + +## HTTP triggers with the private registry + +If your private registry workflow uses an HTTP trigger, note that the gateway endpoint is different from the public registry: + +| Registry | HTTP trigger gateway URL | +| ---------------- | ------------------------------------------------------ | +| Public (onchain) | `https://01.gateway.zone-a.cre.chain.link` | +| **Private** | `https://01.enterprise-gateway.zone-a.cre.chain.link/` | + +Update your `GATEWAY_URL` (or equivalent configuration) wherever you send trigger requests — in local testing, CI scripts, or backend integrations — to use the enterprise gateway URL when targeting private registry workflows. + +See [Triggering Deployed Workflows](/cre/guides/workflow/using-triggers/http-trigger/triggering-deployed-workflows) for the full HTTP trigger request format and authentication details. + +## 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 96278792cd9..ac5091089db 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-05-08" + lastModified: "2026-05-12" --- 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 */} -