Infrastructure

Some Destinations need a persistent state — a deduplication window, a rollup counter, a nightly file export, and a first-party API endpoint backed by a database. The Infrastructure tab lets you attach Cloudflare storage services to your Destination so your code can read and write them directly.

Available services

Service	Good for
D1	SQL database — reporting, subscriber lists, relational data
KV	Key-value store — fast reads, session caches, deduplication
R2	Object storage — file exports, archives, large blobs

Each service you add gets a binding name (for example MY_DB, CACHE, EXPORTS). Bindings are exposed as params.infra.<BINDING_NAME> inside every edge file and every API handler.

You can also open the Visualization tab and see exactly how your infrastructure works.

Using bindings in code

D1 (SQL database)

const row = await params.infra.MY_DB
  .prepare('SELECT * FROM subscribers WHERE email = ?')
  .bind(email)
  .first()

KV (key-value store)

await params.infra.CACHE.put(`dedupe:${orderId}`, '1', { expirationTtl: 86400 })
const seen = await params.infra.CACHE.get(`dedupe:${orderId}`)

R2 (object storage)

await params.infra.EXPORTS.put(
  `orders/${date}.csv`,
  csvString,
  { httpMetadata: { contentType: 'text/csv' } }
)

Simulation and infrastructure

In Simulation, every binding is mocked in memory. D1 queries are captured but not executed, KV and R2 operations use an in-memory Map, and Analytics Engine writes are logged. Nothing persists between simulation runs, and no data reaches production.

Add bindings from the Infrastructure tab before you reference them in code. Variables come from the Variables tab, not Infrastructure.