Skip to content

SYSTEM Cited by 1 source

Cloudflare Local Explorer

Local Explorer is an open-beta introspection UI + API layer released by Cloudflare on 2026-04-13 alongside the cf CLI Technical Preview. It lets developers inspect, manipulate, and seed the simulated resources that Miniflare creates when running Workers locally via Wrangler or the Cloudflare Vite plugin (Source: sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare).

What it covers

Simulated local resources for the products a Worker binds to:

The same operations available via the Cloudflare API and dashboard for these products are now available entirely locally, powered by the same underlying API structure.

UI and access

During wrangler dev (or vite dev with the Cloudflare Vite plugin), the developer is prompted to open Local Explorer via keyboard shortcut e. The GUI shows:

  • The bindings the Worker currently has attached.
  • The data stored against each binding.
  • Seed / inspect / DROP TABLE affordances for the local DB.
  • Schema verification for local data shapes.

The Local Explorer API

Starting 2026-04-13, Local Explorer exposes an HTTP API at /cdn-cgi/explorer/api on any Wrangler- or Vite-plugin-powered application. This is a local mirror of the Cloudflare API:

  • Same endpoints, same request shapes, same response shapes as the production Cloudflare API.
  • OpenAPI specification published at the same path — agents can discover it and call local Cloudflare API operations directly.
  • The upcoming cf uses this endpoint when the user passes --local; every other flag behaves identically between local and remote invocations.

See concepts/local-remote-parity for the design goal and patterns/local-mirror-of-remote-api for the pattern.

Why it matters

Before Local Explorer:

  • Local state lived in .wrangler/state and required reverse-engineering or third-party tools to inspect.
  • Agents using Workers bindings via a local dev server could not tell whether their writes were going local or remote; when developers used remote bindings that mixed local and remote, this divergence surfaced as data inconsistency the agent couldn't explain.

After Local Explorer:

  • One consistent API shape for local and remote — agents see the same tools / responses both ways.
  • Local state introspectable via GUI and API.
  • Agent-driven local-dev cycles: point the agent at /cdn-cgi/explorer/api and it can seed, inspect, and reset local resources itself.

Explicitly pitched for agent-development workflows: "When you build using Agents, Local Explorer is a great way to understand what the agent is doing with data."

Relation to Miniflare

Miniflare provides the simulated runtime; Local Explorer is the introspection and manipulation layer sitting on top of Miniflare's state. Miniflare continues to do the heavy lifting of emulating the Workers runtime locally; Local Explorer just makes its state first-class.

Seen in

Last updated · 200 distilled / 1,178 read