Binding reference Bindings

Use Analytics Engine when the worker should write structured event points, not improvise log transport

Analytics Engine lets Workers write structured data points for later querying and operational analysis.

Analytics Engine is modeled cleanly in Devflare config and generated types, but the repo evidence points to a lighter local story than KV, D1, and R2.

That usually means two good habits: keep the write path simple in the worker, and test the event-producing behavior through a thin boundary rather than by inventing a giant analytics simulation.

Config key
Authoring shape
Best for: Structured analytics or event logging inside worker code

Add the binding to config

The Analytics Engine binding is conceptually simple: pick a dataset name and write data points to it from the worker path that owns the event.

What matters more than the config shape is resisting the urge to build a fake analytics platform around it just to write the first tests.

Analytics Engine binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'analytics-worker',

bindings: {

analyticsEngine: {

APP_ANALYTICS: {

dataset: 'app-analytics'

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first Analytics Engine 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.

Write one analytics point in the worker

import { env } from 'devflare/runtime'

export async function fetch(): Promise<Response> {

env.APP_ANALYTICS.writeDataPoint({

indexes: ['search'],

blobs: ['devflare query']

})

return new Response('recorded')

}

Local and Remote Support

Devflare supports the config, generated env shape, docs, and local application-flow work, but full fidelity requires Cloudflare remote infrastructure. Use local shims or fixtures for code your app owns, then connect to Cloudflare when the product behavior is the assertion.

Supported, but usually tested through integration or thin mocks. Keep local coverage focused on deterministic application flow through fixtures, mocks, shims, or Miniflare-backed wiring instead of pretending to reproduce Cloudflare-hosted product behavior.

Use Cloudflare when analytics delivery itself is a release-critical guarantee. This is the lane for full Analytics Engine product fidelity, remote state, lifecycle behavior, and platform-specific limits.

When this binding fits best

Use Analytics Engine when the worker should record structured event points as part of handling real traffic or jobs.
Keep analytics writes narrow and explicit so they stay easy to review.
If the data is really application state, it probably belongs in D1 or another durable store instead of analytics.

Testing path

The repo does not show a dedicated analytics helper surface comparable to or .
Preview-scoped dataset names can be materialized, but Devflare does not provision or delete datasets because Analytics Engine creates them on first write.
Tests should focus on event-producing behavior rather than pretending you need a full local analytics backend.

This binding is about a write path

Document the write contract clearly and keep the testing story light. That is more useful than inventing an elaborate fake dataset universe.

Open the next page when you need it

Subpage

Analytics Engine internals

Internals

Check emitted Wrangler , preview behavior, and Cloudflare-specific details.

Subpage

Testing Analytics Engine

Testing

Pick the A thin worker test or explicit mock around path first, then move to remote checks only when the test needs them.

Subpage

Analytics Engine example

Example

Copy a fuller application path when the quick example is too small.