# Migrate from Gelato Web3 Functions to Chainlink CRE Source: https://docs.chain.link/cre/reference/gelato-migration-go Last Updated: 2026-02-16 > For the complete documentation index, see [llms.txt](/llms.txt). > **NOTE: SDK Language: Go** > > You're viewing the **Go** version of this guide. If you prefer TypeScript, use the language selector in the left > sidebar to switch to the TypeScript version. This page provides a concise mapping of Gelato Web3 Functions concepts to their CRE equivalents. [CRE](/cre) runs your code across a [Decentralized Oracle Network (DON)](/cre/key-terms#decentralized-oracle-network-don) — a group of independent nodes that each execute your workflow and reach [consensus](/cre/concepts/consensus-computing) on the result. Unlike a single-executor model, every operation — API calls, blockchain reads, onchain writes — is cryptographically verified by multiple nodes, giving your workflows institutional-grade security and reliability with no single point of failure. If any term below is unfamiliar, see the [Key Terms](/cre/key-terms) glossary. ## Terminology The core concepts map closely between platforms, but the names differ: | Gelato | CRE | Notes | | ------------------------------ | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Web3 Function** | **Workflow** | Your compiled application. In CRE, workflows are WASM binaries deployed to a [DON](/cre/key-terms#decentralized-oracle-network-don). | | **`onRun` function** | **Callback** | The function containing your business logic, invoked when a trigger fires. | | **Task** | **Handler** | The binding of a trigger to a callback: `cre.Handler(trigger, callback)`. | | **Trigger (time/event/block)** | **Trigger (cron/EVM log/HTTP)** | The event that starts execution. CRE adds HTTP triggers. | | **Gelato Executor** | **Workflow DON** | The infrastructure that runs your code. CRE uses a Decentralized Oracle Network instead of a single executor. | | **Gelato Relay** | **Capability DON** | The service that performs specific operations (chain writes, HTTP fetches). Each [capability](/cre/capabilities) runs on its own DON with consensus. | | **`userArgs` / `schema.json`** | **Config / `config.json`** | Runtime parameters. CRE uses typed Go structs for configuration schemas. | | **`context.secrets`** | **`runtime.GetSecret()`** | Secret access at runtime. CRE uses a `secrets.yaml` manifest + [Vault DON](/cre/guides/workflow/secrets/using-secrets-deployed) for deployed workflows. | ## Configuration **Gelato** uses a combination of the Gelato UI, SDK, and IPFS for task creation and deployment. Configuration is split between `schema.json` (for `userArgs`), the UI (for triggers and secrets), and your function code. **CRE** consolidates everything into files within your code repository: | File | Purpose | | ---------------------- | --------------------------------------------------------------------------------------- | | `main.go` | Your workflow code (triggers, callbacks, business logic) | | `config..json` | Runtime parameters per target (e.g., `config.staging.json`). Replaces Gelato `userArgs` | | `secrets.yaml` | Declares secret names; values come from `.env` (simulation) or Vault DON (deployed) | | `project.yaml` | Project-level configuration (project name, shared settings) | | `workflow.yaml` | Per-workflow configuration (workflow name, paths to artifacts and config files) | All deployment and management is done through the CRE CLI (`cre workflow simulate`, `cre workflow deploy`, etc.), not a separate UI or IPFS. ## Triggers ### Time-based **Gelato**: Time intervals (e.g., "every 5 minutes") or cron expressions, configured through the UI or SDK. **CRE**: Standard cron expressions (5 or 6 fields) configured directly in your code. Supports timezone prefixes (e.g., `TZ=America/New_York 0 9 * * 1-5`). Minimum interval is 30 seconds. ```go // CRE cron trigger cronTrigger := cron.Trigger(&cron.Config{Schedule: "0 */5 * * * *"}) cre.Handler(cronTrigger, onCronTrigger) ``` See the [Cron Trigger guide](/cre/guides/workflow/using-triggers/cron-trigger) for full details. ### HTTP triggers **Gelato**: Not natively supported as a trigger type. **CRE**: Start a workflow execution in response to an external HTTP request. Supports authentication and passes the request body to your callback. See the [HTTP Trigger guide](/cre/guides/workflow/using-triggers/http-trigger/overview) for details. ### Onchain events **Gelato**: Event-based triggers that watch for smart contract events, configured in the UI. **CRE**: `evm.LogTrigger()` watches for specific contract events. You specify contract addresses and optionally filter by event topics, directly in your workflow code. See the [EVM Log Trigger guide](/cre/guides/workflow/using-triggers/evm-log-trigger) for details. ### Per-block triggers **Gelato**: Native "every block" trigger type. **CRE**: No direct equivalent. Use a short cron interval (e.g., every 30 seconds) or an EVM log trigger to achieve similar behavior. ## Task authoring and output ### Language and runtime **Gelato**: TypeScript running in a Deno-like Node.js environment. Full access to `fetch()`, npm packages, and ethers.js. **CRE**: Go compiled to WASM. Your workflow code is compiled to a WebAssembly binary and executed by DON nodes. The Go SDK provides built-in clients for all common operations (HTTP, EVM, secrets). ### HTTP / API calls **Gelato**: `fetch()` or axios, running on a single executor. **CRE**: `http.SendRequest()` — each DON node fetches independently, and results are aggregated via [consensus](/cre/concepts/consensus-computing). Your API data is validated across multiple nodes before your workflow uses it. CRE also offers a [Confidential HTTP](/cre/capabilities/confidential-http) capability for privacy-preserving API calls — secrets are injected inside a secure enclave and responses can be optionally encrypted. ### Onchain reads **Gelato**: `multiChainProvider.default()` with ethers.js. **CRE**: `evm.Client` with [generated bindings](/cre/guides/workflow/using-evm-client/generating-bindings) for type-safe ABI encoding/decoding and contract interactions. A single workflow can read from and write to [multiple chains](/cre/reference/sdk/evm-client) — no need for separate infrastructure per chain. See the [Onchain Read guide](/cre/guides/workflow/using-evm-client/onchain-read) for details. ### Onchain writes **Gelato**: Return `{ canExec: true, callData: [...] }` from your function. Gelato relays the transaction. **CRE**: Two-step process with consensus verification: 1. Generate a [signed report](/cre/guides/workflow/using-evm-client/onchain-write/overview) with `runtime.GenerateReport()` 2. Submit it onchain with `evm.Client.WriteReport()` ```go // 1. Generate a signed report report, err := runtime.GenerateReport(&cre.ReportRequest{ EncodedPayload: encodedValue, }).Await() // 2. Submit the report onchain (using generated binding helper) txResult, err := contract.WriteReportFromMyResult(runtime, report, &evm.GasConfig{ GasLimit: gasLimit, }).Await() ``` The **[KeystoneForwarder](/cre/guides/workflow/using-evm-client/onchain-write/overview)** contract verifies the DON's signatures before calling your [consumer contract](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts). This is the biggest architectural difference — CRE writes are cryptographically verified by the decentralized network, not relayed by a single executor. See the [Onchain Write guide](/cre/guides/workflow/using-evm-client/onchain-write/overview) and [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts). ### Secrets **Gelato**: `context.secrets.get("KEY")`, configured in the UI. **CRE**: Declare secrets in `secrets.yaml`, provide values via `.env` (simulation) or Vault DON (deployed), access via `runtime.GetSecret()` in your code. The API is the same regardless of environment. See the [Secrets guide](/cre/guides/workflow/secrets) for details. ## Monitoring **Gelato**: Task dashboard in the Gelato UI showing execution history, logs, and status. **CRE**: The [CRE UI](https://app.chain.link/cre/discover) provides: - Workflow status and lifecycle management (active, paused, etc.) - Detailed execution logs and events - Performance metrics and debugging tools See the [Monitoring & Debugging guide](/cre/guides/operations/monitoring-workflows) for details. ## Deployment and lifecycle | Action | Gelato | CRE | | ------------------ | --------------------------------------- | ---------------------------------------------------------------------------- | | **Test locally** | Gelato CLI | `cre workflow simulate` | | **Deploy** | Upload to IPFS + create task via UI/SDK | `cre workflow deploy` | | **Pause / Resume** | UI | `cre workflow activate` / `cre workflow pause` | | **Update** | Redeploy to IPFS + update task | Redeploy with `cre workflow deploy` | | **Delete** | UI | `cre workflow delete` | | **Monitor** | Gelato dashboard | CRE UI at [app.chain.link/cre/discover](https://app.chain.link/cre/discover) | ## Pricing CRE is currently in Early Access. For pricing details, reach out via the in-app support on the CRE platform at app.chain.link/cre/discover. ## Get started You can have a working CRE workflow running locally in minutes: 1. **[Start the Getting Started tutorial](/cre/getting-started/overview)** — build your first workflow from scratch, step by step 2. **[Create your CRE account](https://app.chain.link/cre/discover)** — [Account setup guide](/cre/account/creating-account) 3. **[Install the CRE CLI](/cre/getting-started/cli-installation)** 4. **[Run a demo](/cre/templates/running-demo-workflow)** — see a complete workflow in action with a single command 5. **[Browse the templates](/cre/templates)** — see complete workflow examples you can clone and customize