Deploying to Cloudflare and Fastly

Deploy fully bundled worker graphs to Cloudflare Workers or Fastly Compute with provider-owned assets, snapshots, and storage bindings.

Cloudflare Workers

brix build --platform cloudflare

Deploy dist/app.mjs with a string BRIX_ENV_SNAPSHOT binding and an ASSETS fetcher binding. The production bundle is a native, fully bundled Worker graph and cannot import Node APIs or the DynamoDB adapter. Brix does not generate or run a provider deployment command. Local brix dev still executes through Node rather than workerd.

Fastly Compute

Install the Fastly CLI on PATH, then use either configuration or the CLI flag:

BRIX_ENV_REVISION=release-2026-09-09 brix build --platform fastly

BRIX_ENV_REVISION is currently mandatory even if the application declares no environment keys; it is a non-secret exact resource selector, not a resolved secret. The SDK version is pinned by Brix. The build automatically runs Fastly packaging and writes dist/fastly/pkg; do not run a second fastly compute build. BRIX_ASSET_BACKEND names the asset backend and defaults to assets. Brix overrides that backend during development and neither publishes nor provisions it in production. Resolved secrets are never included in the production package.

An optional project-root fastly.toml contributes local_server fixtures only. Relative fixture file paths resolve from the project root. Unrelated upstream backend, KV, and Secret Store fixtures are retained, while Brix overrides the selected asset backend. If Varlock supplied a local snapshot, it overrides the brix-env fixture; otherwise an authored fixture is used, and if neither exists Brix supplies an empty snapshot. The generated Viceroy manifest and resolved snapshot live in a mode-0600 manifest inside a mode-0700 temporary directory outside the project.

Fastly KV is the native supported shared data cache in Fastly development and production. It has no strong-read option and its invalidation is eventual; it does not purge CDN or browser caches.