Binding reference Bindings

Use AI Search in a Worker

AI Search bindings let Workers search and chat with indexed content from Cloudflare AI Search instances.

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

Start with the config, wire the binding into worker code, then use the support section to decide whether local tests or Cloudflare-backed tests fit.

Config key
Authoring shape
Best for: search/chat flows where the app calls an AI Search instance or namespace from a Worker

Add the binding to config

Add to , then use the generated env binding from Worker code.

Keep the first version close to the route or handler that needs it; move to a helper only after the shape is obvious.

Smallest AI Search config

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'search-worker',

bindings: {

aiSearch: {

DOCS_SEARCH: {

instanceName: 'docs-search'

}

})

Use the binding from application code

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

Search one AI Search instance

import { env } from 'devflare/runtime'

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

const query = new URL(request.url).searchParams.get('q') ?? 'devflare'

const result = await env.DOCS_SEARCH.search({ query })

return Response.json(result.chunks)

}

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.

Offline-fixture: deterministic in-memory instances can test application flow, not hosted relevance behavior. 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 the assertion depends on cloudflare-hosted product behavior rather than the app calling the binding correctly. This is the lane for full AI Search product fidelity, remote state, lifecycle behavior, and platform-specific limits.

When this binding fits best

Use AI Search when search/chat flows where the app calls an ai search instance or namespace from a worker.
Keep binding names stable and uppercase in examples so generated Env declarations remain predictable.
Prefer Devflare native config while it covers the feature; use only for unsupported Wrangler-only fields.

Testing path

Start with with AI Search fixtures for config-backed local worker tests.
Use / for small unit tests that only need deterministic application behavior.
Use Cloudflare-backed tests when the assertion depends on hosted platform behavior, account state, limits, billing, or production routing.

Open the next page when you need it

Subpage

AI Search internals

Internals

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

Subpage

Testing AI Search

Testing

Pick the with AI Search fixtures path first, then move to remote checks only when the test needs them.

Subpage

AI Search example

Example

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