new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Cloudflare Workers · Wrangler · all subjects

bindings

73 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

browser binding configuration

The browser field is an optional object that provides a Worker with an authenticated endpoint to interact with a dedicated Chromium browser instance via the Workers Browser Run API. Contains: binding (required string) - The binding name used to refer to the browser binding. The value will be used to reference this headless browser in the Worker. The binding must be a valid JavaScript variable name.

hyperdrive binding configuration

The hyperdrive field is an optional non-inheritable array that specifies Hyperdrive bindings allowing interaction with Postgres databases from within a Worker. Each Hyperdrive object contains: binding (required string) - The binding name. id (required string) - The ID of the Hyperdrive configuration. When using Hyperdrive, compatibility_flags must include nodejs_compat_v2.

images binding configuration

The images field is an optional object that binds Cloudflare Images to the Worker for making transformation requests to optimize, resize, and manipulate images stored in remote sources. Contains: binding (required string) - The name of the binding used to refer to the Images API.

analytics_engine_datasets binding configuration

The analytics_engine_datasets field is an optional non-inheritable array that specifies Analytics Engine datasets the Worker should be bound to for analytics, observability and data logging. Each dataset object contains: binding (required string) - The binding name used to refer to the dataset. dataset (optional string) - The dataset name to write to. This will default to the same name as the binding if not supplied.

mtls_certificates binding configuration

The mtls_certificates field is an optional non-inheritable array that specifies mTLS certificates for a Worker to present for client authentication in subrequests to origins that require it. Each certificate object contains: binding (required string) - The binding name used to refer to the certificate. certificate_id (required string) - The ID of the certificate. Wrangler displays this via mtls-certificate upload and mtls-certificate list commands.

ai binding configuration

The ai field is an optional object (limited to one AI binding per Worker project) that binds Workers AI allowing the Worker to run machine learning models on the Cloudflare network. Contains: binding (required string) - The binding name.

workflows binding configuration

The workflows field is an optional non-inheritable array that specifies Workflows the Worker should be bound to for creating and managing Workflow instances programmatically. Each workflow binding contains: binding (required string) - The binding name used to refer to the Workflow. Must be a valid JavaScript variable name. name (required string) - The name of the Workflow. class_name (required string) - The name of the exported Workflow class. Must match the Workflow class exported from Worker code. script_name (optional string) - The name of the Worker script where the Workflow class is defined. Only required if the Workflow is defined in a different Worker. schedules (optional string array) - A list of cron schedules that create new instances of this Workflow automatically. Use when wanting to run a Workflow on a recurring interval without defining top-level triggers.crons.

dispatch_namespaces binding configuration

The dispatch_namespaces field is an optional non-inheritable array that specifies dispatch namespace bindings allowing communication between a dynamic dispatch Worker and a dispatch namespace for Workers for Platforms. Each binding contains: binding (required string) - The binding name. namespace (required string) - The name of the dispatch namespace. outbound (optional object) - service (required string when outbound is specified) - The name of the outbound Worker to bind to. parameters (optional array) - A list of parameters to pass data from the dynamic dispatch Worker to the outbound Worker.

Wrangler v2 introduces JSON bindings for vars

Wrangler v2 introduces JSON bindings for vars.

Service binding to Worker in specific environment format

To use a service binding that targets a Worker in a specific environment, append the environment name to the target Worker name in the 'service' field using the format <worker-name>-<environment-name>. For example, if worker-b has a service binding to worker-a in a staging environment, the service field in staging should point to 'worker-a-staging', while the top-level service binding points to 'worker-a'.

Example: service binding between Workers in staging environment

Example showing worker-b with service binding to worker-a in staging: worker-a configuration: ```jsonc { "$schema": "./node_modules/wrangler/config-schema.json", "name": "worker-a", "vars": { "FOO": "<top-level-var>" }, "env": { "staging": { "vars": { "FOO": "<staging-var>" } } } } ``` worker-b configuration: ```jsonc { "$schema": "./node_modules/wrangler/config-schema.json", "name": "worker-b", "services": { "binding": "<BINDING_NAME>", "service": "worker-a" }, "env": { "staging": { "service": { "binding": "<BINDING_NAME>", "service": "worker-a-staging" } } } } ``` The top-level service binding in worker-b points to 'worker-a', while the staging environment binding points to 'worker-a-staging'.

kv_namespaces field in Wrangler v1 configuration

The kv_namespaces field is not inherited and optional. It defines a list of KV namespace bindings for your Worker. Each namespace binding requires: binding (required) - the name of the global variable your code will reference, id (required) - the ID of the KV namespace for wrangler publish, and preview_id (required) - the ID of the KV namespace for wrangler dev and wrangler preview.

KV namespace creation returns binding configuration

When creating a KV namespace with `wrangler kv:namespace create`, the command outputs a configuration block to add to the Wrangler file. For production namespaces, the output includes `{ binding = "<BINDING_NAME>", id = "<NAMESPACE_ID>" }`. For preview namespaces with the `--preview` flag, the output includes `{ binding = "<BINDING_NAME>", preview_id = "<PREVIEW_ID>" }`.

Give your agent this brain