Configure bindings and types

A binding gives Worker code direct access to a Cloudflare resource such as D1, KV, R2, a Queue, or another service.

The binding name becomes a property on env. Configuration defines which resource sits behind that name in each environment. Run wrangler types after changes and avoid hand-maintaining a second type definition that can drift.

{
  "d1_databases": [
    { "binding": "DB", "database_name": "link-vault", "database_id": "..." }
  ]
}

A binding is capability injection: code receives access to one named resource without handling that resource’s credentials. Keep the binding name stable across environments while pointing it at separate development, staging, and production resources. Then application code stays the same and configuration expresses the deployment boundary.

Generated types prove that code and configuration agree at compile time, not that the resource exists or contains the expected schema. Add a startup or smoke request that exercises each critical binding. Also avoid creating a secret-derived client once in global scope. A binding-only deployment may reuse an isolate, leaving that object configured with an older secret; create it from the current env inside the request instead.

Declare the D1 binding created in the next module and generate the environment types.