Devflare Docs
Binding reference Bindings

Use Version Metadata in a Worker

Version Metadata exposes a Worker version id, version tag, and timestamp to code running in that version.

Add the Version Metadata config, call from worker code, and start with the local test path Devflare supports.

Start with the config, wire the binding into worker code, then use the support section to decide whether local tests or Cloudflare-backed tests fit.

Config key
Authoring shape
Best for
responses, logs, and diagnostics that need the current Worker version id, tag, or timestamp

Add the binding to config

Add to , then use the generated env binding from Worker code.

Keep the first version close to the route or handler that needs it; move to a helper only after the shape is obvious.

Smallest Version Metadata config

Use the binding from application code

After Devflare generates the worker env, import from and keep the first Version Metadata path close to the route, handler, or service method that needs it.

Keep this first path small enough that the config, env binding, and user-visible behavior are easy to review together.

Return the current version tag

Local and Remote Support

Devflare can run useful Version Metadata application behavior locally for ordinary development and tests. Cloudflare still owns production limits, quotas, billing, and deployed account behavior.

Offline-native: Devflare can provide deterministic local metadata without Cloudflare state. Start locally with or ; that lane should cover the normal Version Metadata application flow without requiring a Cloudflare connection.

Use Cloudflare when the assertion depends on deployed limits, account state, lifecycle behavior, billing, or other production-only Version Metadata details.

When this binding fits best

  • Use Version Metadata when responses, logs, and diagnostics that need the current worker version id, tag, or timestamp.
  • Keep binding names stable and uppercase in examples so generated Env declarations remain predictable.
  • Prefer Devflare native config while it covers the feature; use only for unsupported Wrangler-only fields.

Testing path

  • Start with or for config-backed local worker tests.
  • Use / for small unit tests that only need deterministic application behavior.
  • Use Cloudflare-backed tests when the assertion depends on hosted platform behavior, account state, limits, billing, or production routing.

Open the next page when you need it