FLARECHECK

RULE INDEX / v0.9

Cloudflare Workers / rule reference

Nine checks.
Zero mystery.

FlareCheck rules target valid configurations that can still behave unexpectedly in production. Every finding has a stable ID, a concrete consequence, an actionable fix, and a link to Cloudflare’s documentation.

$ npx flarecheck --list-rules
INDEX

Choose a check

  1. FC001 Compatibility date RUNTIME
  2. FC002 Node.js compatibility RUNTIME
  3. FC003 Committed secrets SECURITY
  4. FC004 Production observability EVIDENCE
  5. FC005 Environment binding drift CONFIG
  6. FC006 Explicit deploy environment RELEASE
  7. FC007 Recommended JSONC format MAINTENANCE
  8. FC008 Production resource isolation ISOLATION
  9. FC009 Explicit environment routing ROUTING
FC001

Runtime / warning or error

Compatibility date is current

A Worker’s compatibility_date opts it into runtime behavior and compatibility flags available on that date. Cloudflare recommends setting the current date for a new project and updating it occasionally with testing. Old dates remain supported; FlareCheck’s 90-day warning is an intentionally opinionated maintenance signal, not a platform deadline.

A missing or invalid date is an error because the deployed runtime contract is unclear. A stale but valid date is a warning so upgrades remain deliberate.

Cloudflare compatibility date docs ↗

WRANGLER.JSONC

{
  "compatibility_date": "2026-07-24"
}
Update the date, run tests, then deploy.
FC002

Runtime / warning

Node.js compatibility is explicit

Dependencies can use Node.js built-in modules even when your own Worker source does not. Cloudflare calls out a subtle testing trap: the Workers Vitest pool can inject nodejs_compat, allowing tests to pass while the deployed Wrangler configuration lacks the flag.

Not every Worker needs Node APIs, so FC002 is a warning. Keep the flag when your application or dependency graph relies on supported Node built-ins; otherwise ignore this rule explicitly so the decision stays visible.

Cloudflare Workers best practices ↗

WRANGLER.JSONC

{
  "compatibility_flags": [
    "nodejs_compat"
  ]
}
Or run --ignore FC002 when it is intentionally unnecessary.
FC003

Security / error

Likely secrets are not committed in vars

Wrangler vars are plain configuration values and belong in source control. Cloudflare explicitly cautions against storing sensitive information there. FC003 looks for secret-like names such as API keys, tokens, passwords, and client secrets with non-placeholder values.

Remove the value from the configuration, rotate it if it was real, and store the replacement with Wrangler secrets. Local .dev.vars or .env files should also be excluded from Git.

Cloudflare Workers secrets docs ↗

DO NOT COMMIT

{
  "vars": {
    "API_KEY": "live-secret"
  }
}
npx wrangler secret put API_KEY
FC004

Evidence / warning

Production observability is intentional

Workers Logs require observability configuration to persist invocation logs. Without it, the evidence needed during an incident may be missing. FC004 also flags a 100% head sampling rate: Cloudflare documents that the value controls the percentage of requests logged and can affect volume.

Full sampling can be right for low traffic or short investigations. The warning asks teams to choose it deliberately rather than inherit the default accidentally.

Cloudflare Workers Logs docs ↗

WRANGLER.JSONC

{
  "observability": {
    "enabled": true,
    "head_sampling_rate": 0.1
  }
}
Choose a rate that matches traffic and debugging needs.
FC005

Configuration / warning

Every environment declares its bindings

Named Wrangler environments create distinct Workers. Bindings and environment variables are non-inheritable, so a D1, KV, R2, service, or vars declaration at the root does not automatically appear inside env.staging or env.production.

FC005 compares each named environment with root binding categories and reports omissions. The fix is not blind copying: declare the resource intended for that environment, with environment-specific identities.

Cloudflare Wrangler environments docs ↗

NON-INHERITED BINDING

{
  "env": {
    "production": {
      "d1_databases": [{
        "binding": "DB",
        "database_id": "prod-id"
      }]
    }
  }
}
Repeat the binding shape; change the target identity.
FC006

Release / warning

Deploy scripts select an environment

With named environments present, a bare wrangler deploy still targets the top-level Worker. Cloudflare’s environment examples use --env staging and --env production to select a named target. A package script that omits the flag makes the target depend on operator context and is easy to run incorrectly.

FC006 points directly to the script line in package.json. Make production, staging, and preview commands explicit and reviewable.

Cloudflare environment selection docs ↗

PACKAGE.JSON

{
  "scripts": {
    "deploy:prod":
      "wrangler deploy --env production"
  }
}
The environment is visible before the command runs.
FC007

Maintenance / info

Wrangler uses the recommended JSONC format

Wrangler supports JSON, JSONC, and TOML, but Cloudflare recommends wrangler.jsonc for new projects and notes that some newer features are available only with JSON configuration. JSONC also supports comments while matching the configuration shape used in current docs and schema tooling.

TOML remains supported, so FC007 is informational and never reduces the readiness score. Migrate when convenient rather than interrupting a release.

Cloudflare Wrangler configuration docs ↗

WRANGLER.JSONC

{
  "$schema":
    "./node_modules/wrangler/config-schema.json",
  "name": "my-worker"
}
Comments plus editor validation.
FC008

Isolation / warning

Production resources are isolated

Correctly redeclaring bindings is only half the environment problem. A staging binding can still point at the same D1 database, KV namespace, R2 bucket, Hyperdrive configuration, or Vectorize index as production. The configuration is valid, but staging traffic can mutate production state.

FC008 compares binding names and resource identity fields between env.production and every other environment. Give each non-production environment its own stateful resource unless sharing is an explicit, reviewed choice.

Cloudflare environment isolation docs ↗

RISKY TARGET REUSE

"production": {
  "d1_databases": [{
    "database_id": "same-id"
  }]
},
"staging": {
  "d1_databases": [{
    "database_id": "same-id"
  }]
}
Use a different resource ID outside production.
FC009

Routing / warning

Environment routing targets are explicit

A top-level route or routes declaration does not make the intended target of every named environment obvious. A routed production Worker can coexist with staging or preview environments that should use different hostnames—or stay on workers.dev.

FC009 checks routed projects and warns when a named environment declares none of route, routes, or workers_dev. Explicit targets make deploy reviews safer and prevent an environment from silently landing somewhere unintended.

Cloudflare environment routing docs ↗

EXPLICIT PREVIEW TARGET

{
  "route": "api.example.com/*",
  "env": {
    "staging": {
      "workers_dev": true
    },
    "production": {
      "route": "api.example.com/*"
    }
  }
}
Every environment states where it should receive traffic.

Run the complete inspection

Know before
you deploy.

$ npx flarecheck

Or focus adoption with --only FC003,FC005,FC009.