Deploying to the Private Registry

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.

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 to install or update.
  • Early Access approval: Run cre account access to check your status. See Requesting Deploy Access.
  • Logged in: 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.
  • A workflow project: An existing project created with cre init. See Part 1: Project Setup for the TypeScript guide or Go guide.

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:

# 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:

# 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:

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 :          <your-organization-owner>

Compiling workflow...
Workflow compiled successfully

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

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

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

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:

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:

cre workflow list --registry private

You can also view the workflow in the CRE platform 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

cre workflow activate my-workflow --target staging-settings

Example output:

Fetching workflow to activate... Name=my-workflow

Processing activation for workflow ID <your-workflow-id>...
โœ“ Workflow activated successfully

Details:
   Registry:         private
   Workflow Name:    my-workflow
   Workflow ID:      <your-workflow-id>
   Status:           Active
   Owner:            <your-organization-owner>

Pause

cre workflow pause my-workflow --target staging-settings

Example output:

Fetching workflow to pause... Name=my-workflow

Processing pause for workflow ID <your-workflow-id>...
โœ“ Workflow paused successfully

Details:
   Registry:         private
   Workflow Name:    my-workflow
   Workflow ID:      <your-workflow-id>
   Status:           Paused
   Owner:            <your-organization-owner>

Update

Redeploy with the same workflow name to update a private registry workflow. The CLI replaces the existing registration:

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

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:

# 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 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:

# .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

Get the latest Chainlink content straight to your inbox.