Skip to content
open-computeopen-computeopen-compute

Bindings

Use cf’s standard per-product fields. All names share the Worker env namespace.

import { bindings, defineConfig } from "cf/config";


export default defineConfig({
  worker: {
    name: "app",
    entrypoint: "src/index.ts",
    compatibilityDate: "2026-09-08",
    exports: {
      Counter: {
        type: "durable-object",
        storage: "sqlite",
      },
      MyWorkflow: {
        type: "workflow",
        name: "flow",
      },
    },
    env: {
      KV: bindings.kv({ id: "<namespace-id>" }),
      BUCKET: bindings.r2({ name: "files" }),
      DB: bindings.d1({ id: "<database-id>", name: "app" }),
      COUNTER: bindings.durableObject({ worker: "app", exportName: "Counter" }),
      JOBS: bindings.queue({ name: "jobs" }),
      FLOW: bindings.workflow({
        name: "flow",
        worker: "app",
        exportName: "MyWorkflow",
      }),
      AUTH: bindings.worker({
        worker: "auth-worker",
        exportName: "AuthEntrypoint",
      }),
      LOADER: bindings.workerLoader(),
      IMAGES: bindings.images(),
      VERSION: bindings.versionMetadata(),
    },
  },
});

Resource identifiers and names must resolve inside the same account. cf handles standard provisioning where the declared command supports it; server validation rejects missing, cross-account, or unsupported bindings. Do not add the retired generic bindings object or its type/id/permissions records. Operator-owned native extensions reuse services and props; they do not add a public Binding type. See Extensions.

Regenerate local types after changing configuration:

Terminal window
npm exec -- cf workers types

Runtime detail: Runtime APIs · bindings.