Binding reference Bindings

Use Vectorize when the worker really owns similarity search, not just string matching

Vectorize is fully modeled in Devflare config and preview naming, but meaningful tests are still remote-oriented because the index lives on Cloudflare infrastructure.

That makes the docs pattern similar to AI: compile support is strong, preview lifecycle is explicit, and tests should be honest about when they are using the real index versus a fake.

Config key: bindings.vectorize
Authoring shape: Record<string, { indexName: string }>
Best for: Similarity search, embedding-backed lookup, and retrieval paths that belong in the worker

Author it in the simplest shape that still says what you mean

Vectorize authoring is simple in config, but the operational story matters: an index must exist, dimensions must match, and tests should acknowledge that they are calling a real remote system.

Devflare helps by keeping the binding explicit, the index name visible, and preview resource handling deliberate when the preview needs its own index.

Vectorize binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'search-worker',

bindings: {

vectorize: {

DOCUMENT_INDEX: {

indexName: 'document-index'

}

})

When this binding fits best

Use Vectorize when semantic similarity is part of the worker’s real job, not when plain text search is already enough.
It fits best when the worker is already producing or consuming embeddings as part of the application flow.
If the vector store is optional or external to the worker, keep the boundary explicit and do not force Vectorize into every local path.

Notes worth keeping visible

Real Vectorize tests need remote access and an index that actually exists.
Preview-scoped indexes are possible and lifecycle-managed, but they should be created only when the preview really needs isolated vector state.
Local fake vector stores can be useful above the worker boundary, but they are not proof that the real binding path works.

Dimension and index setup are part of the contract

A passing unit test with a fake array is not equivalent to a real Vectorize call against the configured index.

Cloudflare docs vs the Devflare layer

Cloudflare Vectorize docs is the platform reference. This page is the Devflare translation layer: keep readable in source, understand the typed env surface, and know which local, preview, or remote lane actually matches the binding.

Reference

Cloudflare Vectorize docs

Cloudflare Docs

Platform reference for indexes, embeddings, remote querying, and preview-aware index lifecycle.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for indexes, embeddings, remote querying, and preview-aware index lifecycle.	How to author , what the runtime surface looks like, and how Vectorize fits a Devflare project.
Testing and runtime lens	Cloudflare’s docs focus on the real remote product behavior, account requirements, and runtime constraints on the platform.	Remote-oriented; local tests require remote mode or explicit mocks. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape.
When to open it	When you need the platform contract, limits, APIs, or account-level product details.	When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app.

Go deeper only if this one-page guide stops being enough

Subpage

Vectorize internals

Internals

See normalization, Wrangler , and the preview or runtime details behind the authored shape.

Subpage

Testing Vectorize

Testing

Start from in remote mode plus and only escalate when the binding or deployment model genuinely needs it.

Subpage

Vectorize example

Example

Adapt one small end-to-end path before you hide the binding behind a bigger abstraction.