Adapters
standards uses adapters for everything that touches infrastructure — swap backends without changing your schema or hooks.
standards uses adapters for everything that touches infrastructure. Choose your stack per concern; the schema and hooks stay the same.
Available adapters
| Concern | Package | Default backend |
|---|---|---|
| Database | @stndrds/adapter-supabase | Postgres via Supabase |
| Search | @stndrds/adapter-meilisearch | Meilisearch |
| Cache | @stndrds/adapter-redis | Redis |
| Cache (interface) | @stndrds/adapter-cache | Abstract layer used by other adapters |
| Queue | @stndrds/adapter-bullmq | BullMQ on Redis |
| Sandbox | @stndrds/adapter-e2b | E2B sandboxes for agent code execution |
| HTTP framework | @stndrds/adapter-nestjs | NestJS controllers, guards, and interceptors |
| Telemetry | @stndrds/adapter-posthog | PostHog — opt-in fleet metrics and exception capture |
Telemetry is opt-in and zero-config. Call initStandardsTelemetry() once at boot to register PostHog as the sink for agent, platform, and query metrics plus exception capture; every option (apiKey, deploymentId, host, salt, standardsVersion) defaults from environment variables — STANDARDS_POSTHOG_API_KEY, STANDARDS_DEPLOYMENT_ID, STANDARDS_POSTHOG_HOST, STANDARDS_TELEMETRY_SALT — so a deployment only needs the api key and deployment id set. It also installs flush-on-SIGTERM and crash-capture process handlers (disable with processHandlers: false). Tenant ids are hashed with a deployment-local salt before they leave the install. Skip the call (or set STANDARDS_TELEMETRY=off, or pass disabled: true) and the PostHog client is never constructed — the runtime keeps its stdout default.
Why adapters
Each adapter is a thin layer over its backend that conforms to a standards-defined interface (DatabaseAdapter, SearchAdapter, CacheAdapter, and so on). Swap a backend by implementing the interface — the schema definitions, hooks, and UI components are unaffected. This also means you can test your application logic against in-memory adapters (InMemoryCacheAdapter, NoopCacheAdapter) without spinning up external services.
Composing adapters
A typical production backend uses Supabase + Meilisearch + Redis + BullMQ + E2B together. The @stndrds/adapter-nestjs package wires them into your application via the SchemaModule, which accepts adapter instances as configuration. See the NestJS backend guide for a full wiring example.
// @noverify
import { SchemaModule } from "@stndrds/adapter-nestjs";
import { SupabaseDatabaseAdapter } from "@stndrds/adapter-supabase";
import { MeilisearchSearchAdapter } from "@stndrds/adapter-meilisearch";
import { RedisCacheAdapter } from "@stndrds/adapter-redis";
SchemaModule.forRoot({
database: new SupabaseDatabaseAdapter(supabaseClient),
search: new MeilisearchSearchAdapter(meilisearchClient),
cache: new RedisCacheAdapter(redisClient),
});Adapters are wired in your backend application code. Schema definitions — object(), attribute(), registry — are infrastructure-agnostic and carry no adapter dependencies.