Skip to content

Extensions

Extensions are first-party modules compiled into the API image. They are not downloaded, installed, or provisioned — the code is already in the image you run. Breeze currently ships one: Workspace.

Compiled in is not the same as loaded. Every built-in is off by default and loads at boot only when its deployment enable flag is set. A built-in that is switched off costs nothing: no migrations run, no tables are created, and none of its infrastructure requirements apply.

Extension Enable flag Notes
Workspace (file/email indexing and content search) BREEZE_WORKSPACE_ENABLED Requires a Postgres image with pgvector available

The flag is strict: only the exact string true enables the extension.


When its flag is set, the extension’s migrations are applied at API startup and its manifest-declared contributions become active:

  • HTTP routes, mounted at /api/v1/ext/<name>/… with an alias at /api/v1/<routeNamespace>/…. They run in-process against the same request-scoped, RLS-bounded database handle core routes use.
  • Web surfaces — pages, navigation entries, and slot elements — discovered by the web app through GET /api/v1/extensions/registry.
  • Background jobs and AI tools, where the manifest declares them.

A built-in is required code shipped inside the image, so any failure while loading one (migration, staging, validation, activation) aborts API startup rather than degrading silently.

  • No third-party extension mechanism. There is no way to add an extension to a running deployment; the set of extensions is whatever the image was built with.
  • No signed runtime bundles. There is no artifact format, no packing or signing tool, no extensions.yaml, and no extensions directory to mount.
  • No per-organization activation. An enabled extension serves every organization on the server. There are no per-org install or activation endpoints.

Set the flag on the API service and restart:

Terminal window
BREEZE_WORKSPACE_ENABLED=true

Workspace’s migrations run CREATE EXTENSION vector on boot, so the database must be a pgvector-capable Postgres. The POSTGRES_IMAGE_REF that Breeze ships by default (pgvector/pgvector:pg16) already includes it; if you supply your own Postgres image, provide pgvector before setting the flag or the API will fail to start with extension "vector" is not available. See Production deployment for the database details, including the upgrade caveat about swapping images over an existing data volume.