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

deployment & publishing

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

Setting compatibility flags via Cloudflare Dashboard

Compatibility flags can be updated in the Workers settings on the Cloudflare dashboard at https://dash.cloudflare.com/.

Setting compatibility flags via Cloudflare API

Compatibility flags can be set when uploading a Worker using the Workers Script API or Workers Versions API in the request body's metadata field.

workers.dev recommended use cases

The workers.dev subdomain is recommended for personal or hobby projects that are not business-critical. It is treated as a Free website. It is recommended to run production Workers on a Workers route or custom domain instead.

wrangler versions view command

The `wrangler versions view` command views details of a specific Worker version. Minimum required wrangler version is 3.40.0. For versions before 3.73.0, the `--x-versions` flag is required.

wrangler deploy command syntax and flags for production deployment

The `wrangler deploy` command deploys a Worker to Cloudflare. Syntax: `wrangler deploy [<PATH>] [OPTIONS]`. PATH can be an entry point for the Worker (only required if wrangler configuration file does not include `main` key) or path to assets directory for static site deployment (overrides eventual `assets` configuration and only works in interactive mode). When run without a Wrangler configuration file, Wrangler automatically detects your framework and prompts to confirm settings. For AI agents or environments before Cloudflare authentication is available, use `--temporary` (requires Wrangler 4.102.0 or later) which creates or reuses a temporary preview account, deploys to it, and prints a claim URL. To configure without deploying, use `wrangler setup` instead. Flags include: `--name` (Worker name), `--no-bundle` (skip build steps, default false), `--env` (specific environment), `--outdir` (path to directory where bundled files are written), `--compatibility-date` (date in yyyy-mm-dd form), `--compatibility-flags` (compatibility check flags), `--latest` (use latest runtime, default true), `--assets` (folder of static assets, beta), `--site` (deprecated, use --assets), `--site-include` (gitignore-style patterns for inclusion), `--site-exclude` (gitignore-style patterns for exclusion), `--var` (key:value pairs for variables), `--define` (key:value pairs to replace global identifiers), `--triggers/--schedule/--schedules` (cron schedules), `--routes/--route` (routes for deployment), `--domain` (custom domains), `--tsconfig` (path to custom tsconfig.json), `--minify` (minify before deploying), `--dry-run` (compile without deploying, default false), `--keep-vars` (prevent Wrangler from overriding environment variables, default false), `--secrets-file` (path to file with secrets in JSON or .env format), `--dispatch-namespace` (Workers for Platforms dispatch namespace), `--metafile` (file to write esbuild build metadata to), `--containers-rollout` (immediate/gradual/none, default gradual), `--strict` (stricter mode to prevent potential issues, default false), `--tag` (tag for Worker version), `--message` (descriptive message for version and deployment), `--yes` (skip confirmation prompts, default false), `--temporary` (deploy with temporary preview account).

wrangler versions upload command

The `wrangler versions upload` command uploads a new version of a Worker that is not deployed immediately. Minimum required wrangler version is 3.40.0. For versions before 3.73.0, the `--x-versions` flag is required.

wrangler versions deploy command

The `wrangler versions deploy` command deploys a previously created version of a Worker all at once or creates a gradual deployment to incrementally shift traffic to a new version by following an interactive prompt. Non-interactive version: `wrangler versions deploy version-id-1@percentage-1% version-id-2@percentage-2 -y`. Example: `wrangler versions deploy 095f00a7-23a7-43b7-a227-e4c97cab5f22@10% 1a88955c-2fbd-4a72-9d9b-3ba1e59842f2@90% -y`. Minimum required wrangler version is 3.40.0. For versions before 3.73.0, the `--x-versions` flag is required.

wrangler versions list command

The `wrangler versions list` command retrieves details for the 10 most recent versions. Details include Version ID, Created on, Author, Source, and optionally Tag or Message. Minimum required wrangler version is 3.40.0. For versions before 3.73.0, the `--x-versions` flag is required.

wrangler rollback command syntax

The `wrangler rollback` command creates a new deployment with a specified version of a Worker and makes it the active deployment across all deployed routes and domains. Syntax: `wrangler rollback [<VERSION_ID>] [OPTIONS]`. VERSION_ID is optional; if not supplied, rollback defaults to the version uploaded before the latest version. Flags include: `--name` (perform on specific Worker rather than inheriting from configuration), `--message` (add message for rollback, accepts empty string; when specified, interactive prompts are skipped). A rollback will immediately affect all deployed routes and domains and does not affect local development environment.

wrangler deployments status command

The `wrangler deployments status` command shows the status of deployments for a Worker. Minimum required wrangler version is 3.40.0. For versions before 3.73.0, the `--x-versions` flag is required.

wrangler deploy --var flag example

The `--var` flag in `wrangler deploy` accepts key:value pairs to inject as variables. Example: `--var git_hash:$(git rev-parse HEAD) test:123` makes the `git_hash` and `test` variables available in the Worker's `env`. The value is always passed as a string. This flag is an alternative to defining `vars` in wrangler.toml, and if defined in both places, the flag's values take precedence.

wrangler deploy --define flag example

The `--define` flag in `wrangler deploy` accepts key:value pairs to replace global identifiers in code at build time. Example: `--define GIT_HASH:$(git rev-parse HEAD)` replaces all uses of `GIT_HASH` with the actual value. This flag is an alternative to defining `define` in wrangler.toml, and if defined in both places, the flag's values take precedence.

wrangler deploy --dry-run usage

The `--dry-run` flag compiles a project without actually deploying to live servers. Combined with `--outdir`, this is useful for testing the output of `wrangler deploy`. It also gives developers a chance to upload the generated sourcemap to a service like Sentry so errors from the Worker can be mapped against source code before the service goes live.

wrangler deploy --keep-vars flag

The `--keep-vars` flag (default false) controls whether Wrangler overrides environment variables on deployment. Best practice is to treat the Wrangler developer environment as the source of truth and avoid making changes via the Cloudflare dashboard. If you change environment variables in the dashboard, Wrangler will override them on the next deploy. To disable this behavior, set `--keep-vars` to true. Secrets are never deleted by a deployment whether this flag is true or false.

Give your agent this brain