Chainlink CRE, the Chainlink Runtime Environment, is an orchestration layer where developers write workflows in Go or TypeScript that run when a trigger fires, then call APIs, read and write across blockchains, and handle secrets, with a decentralized oracle network (DON) reaching consensus on every result, per the CRE documentation. Chainlink announced CRE as live on November 4, 2025, in its launch post.
​

CRE also matters for teams already on Chainlink: its docs present it as the destination for Chainlink Automation upkeeps and for Chainlink Functions subscriptions, whose mainnet service shut down on June 30, 2026, per the Functions migration guide. This page covers how workflows run, what confidential execution adds, how migration works, and where CRE sits next to other offchain compute tools. Sources were fetched October 21, 2026.
​

A CRE workflow is a Go or TypeScript project compiled to WebAssembly and run on a Workflow DON. It contains handlers, and each handler pairs one trigger with one callback. Inside the callback, SDK clients invoke capabilities such as HTTP, EVM read and write, or Solana read and write, and the DON reaches consensus on the results.
​

The CRE key terms page defines the moving parts. A trigger is the event source: a cron schedule, an HTTP request, or an onchain log. A capability is a decentralized microservice backed by its own DON, and developers reach it through clients like EVMClient, SolanaClient and HTTPClient rather than directly. CRE runs two kinds of DONs: Workflow DONs that orchestrate, and Capability DONs that execute specific tasks such as blockchain interactions.
​

Consensus comes in two modes. The Runtime object handles operations with a built-in Byzantine Fault Tolerant guarantee. The NodeRuntime object, used inside RunInNodeMode, has each node do the work on its own and leaves the developer to supply the aggregation, for example taking a median of API responses. When a callback finishes, it can produce a report, a signed package of payload bytes and DON signatures, then deliver it onchain with writeReport() or offchain with sendReport().
​

Workflows are managed through a control plane with two modes, per the key terms page. A public workflow is registered in the Workflow Registry contract on Ethereum Mainnet and needs a linked wallet and gas. A private workflow uses the Chainlink-hosted private registry with no wallet or gas. The docs stress that private does not mean confidential.
​

CRE supports two chain families, EVM-compatible chains and Solana. The supported networks page lists 24 EVM mainnets, including Ethereum, Arbitrum One, Base, BNB Chain, Avalanche, Polygon and Plasma, plus Solana Mainnet and Devnet. Each network requires a minimum CLI and SDK version, so older projects may need updates.
​

Per the supported networks page, modified October 19, 2026, Solana is supported for reads, writes and log triggers from CRE CLI v1.33.0. The same page notes that safe and finalized reads are not reliably supported on Mantle, Polygon and Scroll, which affects workflows that wait for finality. The CRE docs homepage dates full Solana support, including Solana Read and the Solana Log Trigger, to October 19, 2026.
​

CRE offers two confidential execution features built on trusted execution environments. Confidential HTTP runs a single outbound API call inside an enclave, keeping credentials and optionally the response hidden from node operators. Confidential Workflows, in invite-only private beta, run a handler's full callback logic inside an enclave and cross back to the DON for consensus.
​

By default, workflow code and its secrets run on Workflow DON nodes, where operators can in principle inspect the computation, per the confidential workflows page. A confidential workflow hands the triggered request to an enclave, fetches secrets inside it, and only completes after DON consensus verifies the enclave's attestations. Triggers, chain reads and chain writes still execute on Workflow DON nodes, and source code, deployed binaries and reports are not protected. Chainlink's listed use cases include liquidation protection, portfolio rebalancing and payment orchestration, where exposed thresholds could be front-run.
​

Confidential HTTP changes the consensus target. With regular HTTP, every node calls the API and nodes agree on the response. With Confidential HTTP, nodes agree on the request parameters, secrets from the Vault DON are threshold decrypted inside the enclave, and exactly one call is made. The response can be AES-GCM encrypted with EncryptOutput. Data transformation inside the enclave is not yet supported. For background on the hardware model, see What Is a Trusted Execution Environment?
​

Chainlink describes CRE as a functional superset of both Automation and Functions. Automation upkeeps map to cron or EVM log triggers plus a signed report delivered to an IReceiver contract. Functions requests map to a workflow with an HTTP fetch and the same report flow. Both migrations require deploying a new receiver contract and re-registering secrets.
​

For Automation, the Automation migration guide maps a time-based upkeep to the cron trigger, a log trigger upkeep to the EVM Log trigger, and custom logic upkeeps to a cron trigger plus callContract() reads in the handler. The fastest path is the Automation Migration template, which deploys a generic AutomationReceiver.sol bridge that forwards approved calls to the existing performUpkeep. Teams must authorize each target and function selector with setCallAllowed(), and the guide recommends workflow identity checks before production. CRE supports every chain Automation runs on. The last step is cancelling the old upkeep and withdrawing its LINK so both do not run at once.
​

For Functions, the Functions migration guide replaces inline JavaScript sent through sendRequest() with a full TypeScript or Go project. The fulfillRequest() callback becomes _onReport() on a receiver. Two details catch teams out. DON-hosted Functions secrets cannot be exported, so they must be registered again with the cre CLI. And CRE covers every Functions chain except Soneium (mainnet and Minato testnet) and the Celo Alfajores testnet. The cron trigger has a minimum interval of 30 seconds, and there is no per-block trigger.
​

CRE runs workflow logic across a decentralized oracle network with consensus on results, and adds TEE execution where needed. Goldsky Compose runs TypeScript tasks in traced sandboxes that can run as a TEE or a normal container. Oasis ROFL runs containerized apps inside TEEs on Oasis nodes, managed through the Sapphire chain.

The practical split is the trust model. CRE's default guarantee comes from many independent nodes agreeing, while Compose and ROFL lean on hardware attestation from a TEE, per Goldsky's Compose introduction and the Oasis ROFL docs. CRE fits when a team wants DON-signed reports consumed onchain; a TEE-first framework fits when one attested process is enough. A broader map sits in smart contract automation tools.
​

Some workflows also need to move stablecoins between chains, for example a rebalancing job that sends USDC from Base to Arbitrum. CRE handles the trigger and the logic; the transfer leg can go through an intent-based route such as the Eco Routes API, which lets an app request a quote, fund a transfer and track its status.
​

CRE has real limits. Confidential Workflows are invite-only beta, and confidential execution does not cover triggers, chain reads or writes, or source code. Migration is not drop-in: receivers must be redeployed, Functions secrets re-entered, and two chains dropped. Finality-dependent reads are unreliable on Mantle, Polygon and Scroll.
​

Workflow callbacks must also be deterministic so every node reaches the same answer, which rules out patterns like reading the system clock with Date.now(); the Functions migration guide tells developers to use runtime.now() instead. Regular HTTP calls run once per node, so non-idempotent POSTs need cacheSettings to avoid duplicate requests, per the Confidential HTTP page. And a public workflow's lifecycle actions cost Ethereum Mainnet gas, while the gas-free private registry is centralized and offchain, per the key terms page.
​

These short answers cover the questions developers most often raise when first evaluating CRE. Each answer draws on the Chainlink documentation pages cited throughout this article, fetched on October 21, 2026, and should be checked against the live docs before a production migration, since CRE releases change version requirements often.
​

No. Functions ran an inline JavaScript string per request; CRE runs compiled Go or TypeScript workflows with multiple triggers and steps, per the Functions migration guide.
​

No. Private refers to the registry. Confidentiality requires Confidential HTTP or a Confidential Workflow, per the key terms page.
​

The Chainlink oracle network. For background, see What Is Chainlink?
​

All CRE facts come from Chainlink's own documentation and launch post; comparison rows come from each vendor's own docs. Every page was fetched October 21, 2026. Network lists and CLI versions change with each CRE release, so check the supported networks page before deploying.