Application example Bindings

Use Pipelines in a real application path

Pipelines bindings let Workers send event records into Cloudflare-managed ingestion pipelines.

A compact Pipelines 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.pipelines
Runtime shape
Best use: Worker-side event ingestion into Cloudflare Pipelines

Start by wiring the binding clearly in config

Smallest Pipeline config

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'events-worker',

bindings: {

pipelines: {

EVENTS: 'app-events'

}

})

Build the application flow around the binding

Treat this as the app-level Pipelines 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.
Devflare records local sends but does not create pipelines, manage R2 sinks, or emulate production batching.

Send one record batch

import { env } from 'devflare/runtime'

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

await env.EVENTS.send([

{ timestamp: Date.now(), message: 'signup' }

])

return new Response('recorded')

}

Keep production boundaries visible

Config focus: bindings.pipelines.
Runtime shape: .
Best use: Worker-side event ingestion into Cloudflare Pipelines.

Thread this into the next recipe

Once this smallest path works, add routing, generated types, and feature-specific abstraction in that order.

Testing Pipelines

Test Pipelines by choosing the local harness that matches the product boundary instead of reaching for Cloudflare by default.

Images

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