Updating Deployed Workflows
When you update a deployed workflow, you redeploy it with the same workflow name and the same deployment-registry target. The new deployment replaces the previous version in that registry. Currently, CRE does not maintain version history—each deployment overwrites the previous one.
Prerequisites
Before updating a deployed workflow, ensure you have:
- A deployed workflow: The workflow must already 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.yamlfile to identify which workflow to update. - Logged in: Authenticated with the platform by running
cre login. To check if you are logged in, runcre whoami. - (Optional)
deployment-registryinworkflow.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. - (Onchain registry only) A funded wallet: The account must be funded with ETH on Ethereum Mainnet to pay gas for the registry transaction.
Updating a workflow
To update a workflow, simply redeploy it using the same workflow name:
cre workflow deploy my-workflow --target production-settings
What happens during an update
- Compilation: Your updated workflow code is compiled to WASM
- Upload: The new binary and configuration files are uploaded to the CRE Storage Service
- Registration: The new workflow version is registered with the target's configured registry. For
onchain:ethereum-mainnet, this sends a transaction to the Workflow Registry contract. Forprivate, this updates the Chainlink-hosted private registry through your CRE login session. - Replacement: The previous version is replaced with the new deployment
- Status preserved: The workflow's status (active or paused) is preserved from the previous deployment
Best practices for updates
- Test locally first: Always test your changes using
cre workflow simulatebefore deploying to production - Pause before updating (optional): If you want to ensure no triggers fire during the update, pause the workflow first using
cre workflow pause - Monitor after deployment: Check that the updated workflow executes correctly after deployment
- Keep track of changes: Maintain your own version control (e.g., Git tags) to track workflow versions
Using multi-sig wallets
For onchain registry workflows, 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. 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.
Learn more
- Deploying Workflows — Learn about the initial deployment process
- Activating & Pausing Workflows — Control workflow execution state
- Deleting Workflows — Remove workflows from the registry