bindings configuration

22 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Add AI binding to Worker via Wrangler configuration

To add an AI binding to your Worker, include the binding configuration in your Wrangler configuration file (wrangler.toml).

KV namespace binding in Terraform

To bind a KV namespace in Terraform, use a binding with `type = "kv_namespace"`, `name` (the variable name, e.g., 'MY_KV'), and `namespace_id` (the ID of your KV namespace). Access via `env.MY_KV`.

R2 bucket binding in Terraform

To bind an R2 bucket in Terraform, use a binding with `type = "r2_bucket"`, `name` (the variable name, e.g., 'MY_BUCKET'), and `bucket_name` (the name of your R2 bucket). Access via `env.MY_BUCKET`.

D1 database binding in Terraform

To bind a D1 database in Terraform, use a binding with `type = "d1"`, `name` (the variable name, e.g., 'DB'), and `id` (the ID of your D1 database). Access via `env.DB`.

Durable Object binding in Terraform

To bind a Durable Object in Terraform, use a binding with `type = "durable_object_namespace"`, `name` (the variable name, e.g., 'MY_DURABLE_OBJECT'), `class_name` (the exported class name), and optionally `script_name` (the Worker script that exports this class; omit if defined in the same Worker). Access via `env.MY_DURABLE_OBJECT`.

Service binding in Terraform

To bind another Worker for Worker-to-Worker communication in Terraform, use a binding with `type = "service"`, `name` (the variable name, e.g., 'MY_SERVICE'), `service` (the name of the target Worker), and optionally `entrypoint` (the named entrypoint to bind to). Access via `env.MY_SERVICE`.

Queue binding in Terraform

To bind a Queue for producing messages in Terraform, use a binding with `type = "queue"`, `name` (the variable name, e.g., 'MY_QUEUE'), and `queue_name` (the name of your Queue). Access via `env.MY_QUEUE`. For consuming messages, configure the Worker as a consumer in the queue resource itself, not via bindings.

Vectorize binding in Terraform

To bind a Vectorize index in Terraform, use a binding with `type = "vectorize"`, `name` (the variable name, e.g., 'VECTORIZE_INDEX'), and `index_name` (the name of your Vectorize index). Access via `env.VECTORIZE_INDEX`.

Workers AI binding in Terraform

To bind Workers AI in Terraform, use a binding with `type = "ai"` and `name` (the variable name, e.g., 'AI'). Access via `env.AI`. No additional properties are required.

Hyperdrive binding in Terraform

To bind a Hyperdrive configuration in Terraform, use a binding with `type = "hyperdrive"`, `name` (the variable name, e.g., 'HYPERDRIVE'), and `id` (the ID of your Hyperdrive configuration). Access via `env.HYPERDRIVE`.

VPC Service binding in Terraform

To bind a VPC Service in Terraform, use a binding with `type = "vpc_service"`, `name` (the variable name, e.g., 'PRIVATE_API'), and `service_id` (the ID of your VPC Service from cloudflare_connectivity_directory_service or the dashboard). Access via `env.PRIVATE_API`. Create VPC Services using the `cloudflare_connectivity_directory_service` Terraform resource.

Analytics Engine binding in Terraform

To bind an Analytics Engine dataset in Terraform, use a binding with `type = "analytics_engine"`, `name` (the variable name, e.g., 'ANALYTICS'), and `dataset` (the name of your Analytics Engine dataset). Access via `env.ANALYTICS`.

Plain text environment variable binding in Terraform

To bind a plain text environment variable in Terraform, use a binding with `type = "plain_text"`, `name` (the variable name, e.g., 'MY_VARIABLE'), and `text` (the value of the environment variable). Access via `env.MY_VARIABLE`.

Secret text binding in Terraform

To bind an encrypted secret in Terraform, use a binding with `type = "secret_text"`, `name` (the variable name, e.g., 'API_KEY'), and `text` (the secret value, which will be encrypted). Access via `env.API_KEY`.

Terraform binding array structure

In Terraform, bindings are configured as a single `bindings` array in the `cloudflare_worker_version` resource, where each binding is an object with a `type` property and type-specific properties. This differs from Wrangler's separate top-level properties for each binding type (like `kv_namespaces`, `r2_buckets`, etc.).

Durable Object migration requirement for binding

Durable Object migrations must be applied via deployment before you can bind to a Durable Object in a Worker version. This means you cannot successfully create a version with a Durable Object binding on the first Terraform apply. Workaround: comment out the binding, apply, uncomment it and comment out migrations, then apply again.

D1 database binding configuration in wrangler.json

Add d1_databases to wrangler.json with the following structure: binding (string) is the name used to access the database in code, database_name (string) is the name of the database, and database_id (string) is the unique identifier for your database. Example: { "d1_databases": [{ "binding": "DB", "database_name": "members-db", "database_id": "<unique-ID>" }] }

Create D1 database with wrangler d1 create command

Use the command 'npx wrangler d1 create <database-name>' to create a new D1 database. The command prompts for: binding name (what to use in code), whether Wrangler should add it to the configuration file, and whether to connect to remote resource for local development. If you choose not to connect to remote for local dev, a local SQLite file will be created.

Execute schema file against D1 database

Use 'npx wrangler d1 execute <database-name> --file=./path/to/schema.sql' to execute SQL against the local development database. Use 'npx wrangler d1 execute <database-name> --remote --file=./path/to/schema.sql' to execute against the remote production database.

Create D1 database schema with DROP TABLE IF EXISTS for idempotency

Write schema files with DROP TABLE IF EXISTS statements before CREATE TABLE to ensure the schema can be executed multiple times without errors. This is important for deploying schema changes to both local and remote databases.

Sample D1 Members table schema

CREATE TABLE IF NOT EXISTS members ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL UNIQUE, joined_date TEXT NOT NULL );

Do not add bindings unless build fails

When migrating from Pages to Workers, do not add KV, D1, or other bindings unless your build explicitly fails and requires them.

Give your agent this brain