Wrangler Config

Wrangler Config — No Config/Env Values Here (Infisical is the one place)

wrangler.jsonc / wrangler.toml is for the Worker’s structural wiring only, not for configuration values. There is exactly ONE place to configure what a Worker runs with: Infisical (see the infisical-secrets skill). Keep the two from overlapping — a value in two places drifts.

Never put in a wrangler file

• vars / [vars] — plaintext env/config. This includes non-secret config (public URLs, service names, feature flags, log levels): suggest putting it in Infisical too, so there’s a single source. It then reaches the Worker via the Infisical → CF Workers integration and local dev via infisical export > .dev.vars.
• Secrets of any kind — never inline, never in vars.

Belongs in a wrangler file (structural — keep here)

CF resource/topology declarations are NOT values; Infisical cannot express them, so they stay:

• name, main, compatibility_date, compatibility_flags, account_id
• bindings: hyperdrive, r2_buckets, kv_namespaces, d1_databases, queues, durable_objects, services, vectorize, assets, …
• routes / custom_domain, observability, triggers.crons
• per-env env.<name> blocks for the above (bindings are NOT inherited — re-declare per env; see deployment.md).

Rule of thumb

If it’s a value the code reads off env → Infisical (typed via the secret-env-typing rule). If it’s a binding / resource / runtime flag wrangler needs to build & deploy → the wrangler file. When unsure, it’s probably a value → Infisical.

Why

A value committed in vars is un-rotatable without a redeploy and is baked into git history; split config across wrangler + Infisical is two sources that silently diverge. Wrangler file answers “what resources this Worker binds”; Infisical answers “what values it runs with”.