Use Version Metadata in a real application path
Version Metadata exposes a Worker version id, version tag, and timestamp to code running in that version.
A compact Version Metadata recipe with config and worker usage in one application path.
Use this as the copyable starter before threading the feature into a larger application.
- Config focus
- bindings.versionMetadata
- Runtime shape
- Best use
- responses, logs, and diagnostics that need the current Worker version id, tag, or timestamp
Start by wiring the binding clearly in config
Smallest Version Metadata config
Build the application flow around the binding
Treat this as the app-level Version Metadata path: the route, event handler, or service module receives a real request and uses the binding to do useful work.
Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.
- Keep the first example short enough to paste into a new Worker.
Return the current version tag
Keep production boundaries visible
- Config focus: bindings.versionMetadata.
- Runtime shape: .
- Best use: responses, logs, and diagnostics that need the current Worker version id, tag, or timestamp.
Thread this into the next recipe
Once this smallest path works, add routing, generated types, and feature-specific abstraction in that order.
Previous
Testing Version Metadata
Test Version Metadata by choosing the local harness that matches the product boundary instead of reaching for Cloudflare by default.
Next
Worker Loaders
Add the Worker Loaders config, call from worker code, and start with the local test path Devflare supports.