Cloudflare Workers

A Cloudflare Worker component is a Bit app component that uses the Cloudflare Workers app type and the Cloudflare Workers deployer to build, run, and deploy a Cloudflare Worker directly from your workspace.

The fastest way to get started is to fork the ready-to-deploy backend.cloudflare/examples/cloudflare-worker example — change the handler, set your credentials, and deploy.

Forking creates your own copy of the example in a scope you own — you can then modify and deploy it independently. Run the following from your workspace, replacing my-org.my-scope with your own scope:

$bit fork backend.cloudflare/examples/cloudflare-worker workers/cloudflare-worker --scope my-org.my-scope

Copied

This copies the component into your workspace under your scope. The forked component contains:

• cloudflare-worker.ts — the worker handler (fetch entry point).
• cloudflare-worker.bit-app.ts — the Bit app definition that wires the handler to the Cloudflare deployer.
• cloudflare-worker-types.d.ts — type declarations for @cloudflare/workers-types/experimental.

Open cloudflare-worker.bit-app.ts and update the options to match your Cloudflare account and worker setup:

import { WorkerApp } from '@backend/cloudflare.app-types.cloudflare-workers';
import {
  CloudflareWorker,
  type CloudflareWorkerOptions,
} from '@backend/cloudflare.deployers.cloudflare-workers';

const cloudflareOptions = {
  accountId: process.env.CLOUDFLARE_ACCOUNT_ID,
  apiToken: process.env.CLOUDFLARE_WORKER_API_TOKEN,
  workerName: 'my-worker', // pick a unique name
  mainFile: 'worker.js',
  compatibility_date: '2026-05-01',
  compatibility_flags: ['nodejs_compat'],
  bindings: [
    {
      type: 'plain_text',
      name: 'MESSAGE',
      text: 'Hello from my worker!',
    },
  ],
} satisfies CloudflareWorkerOptions;

export default WorkerApp.from({
  name: 'cloudflare-worker',
  mainPath: import.meta.resolve('./cloudflare-worker.js'),
  deploy: CloudflareWorker.deploy(cloudflareOptions),
});
Copied

Create the API token from the Cloudflare dashboard.

Edit cloudflare-worker.ts to implement your logic. The default handler reads a binding and returns a Response:

import type {
  Request as WorkerRequest,
  ExecutionContext,
} from '@cloudflare/workers-types/experimental';

interface Env {
  MESSAGE: string;
}

export default {
  fetch(request: WorkerRequest, env: Env, ctx: ExecutionContext) {
    return new Response(env.MESSAGE);
  },
};
Copied

Add bindings (KV, R2, D1, secrets, etc.) to the bindings array in the app file and reflect them in the Env interface.

Run the following to run the worker locally:

$bit run cloudflare-worker

Copied

The output should be similar to the following:

Deployment runs automatically via the configured CloudflareWorker.deploy function — when you snap and export your component to a lane, Ripple CI builds the worker and ships it to Cloudflare under the workerName you set.

Create a lane to preview the deployment:

$bit lane create my-lane --scope my-org.my-scope

Copied

Snap the changes:

$bit snap --message "deploy my worker"

Copied

Export to deploy:

$bit export COMPONENT_PATTERNS... --eject --all --all-versions --origin-directly --resume STRING --head-only --ignore-missing-artifacts --fork-lane-new-scope --open-browser --json

Copied

Once Ripple CI finishes building, your worker is live on Cloudflare.

When you're happy with how the worker runs on the preview lane, release the lane to ship the changes to production. Open the change request from the lane page on Bit Cloud and merge it — once merged, the updated component is published to main and the worker is deployed from there.