Configuration

DriftWatch has two typed, Zod-validated config objects — one owned by the SDK, one owned by the reference server — plus one file that isn't env-driven at all (model-client.ts). Nothing else in the codebase reads process.env directly; every function takes its config as a plain typed parameter, so you can build one however your app already manages config (env, a parsed .env, a literal object in tests, convict/t3-env/etc).

SDK config — DriftWatchConfig

Schema: packages/sdk/src/config/schema.ts. Env loader: loadDriftWatchConfigFromEnv().

import { DriftWatchConfigSchema, loadDriftWatchConfigFromEnv } from '@driftwatch/sdk';

const config = loadDriftWatchConfigFromEnv(); // convenience: reads process.env

// or build one however you want, validated against the same schema:
const config = DriftWatchConfigSchema.parse({
  telemetry: { serviceName: 'checkout-agent', environment: 'production' },
  agent: { maxSteps: 12 },
  driftDetection: { signozBaseUrl: 'https://signoz.internal' },
});

telemetry

agent

driftDetection

Server config — ServerConfig

Schema: packages/server/src/config/server-config.ts. Specific to the reference Fastify app, not the SDK — kept separate deliberately.

Boolean env vars are parsed as === '1', not JS truthiness — DRIFT_DRY_RUN=0 is falsy, but so is DRIFT_DRY_RUN=false (any value other than the literal string '1' is false). Same for OTEL_CAPTURE_PAYLOADS, but inverted: only the literal string '0' disables it, anything else (including unset) keeps the default true.

Inline guardrails — agent (SDK, per-request)

Synchronous, per-/run caps enforced inside the generateText loop, so a runaway request aborts before the async drift loop could ever see it. Fields live on DriftWatchConfig.agent (packages/sdk/src/config/schema.ts).

Autopilot — ServerConfig (Loop 2)

The drift-triggered remediation loop and its channels. All server-owned.

Notification / approval channels

Approvals are channel-agnostic — the same pending approval can be resolved from the console, a Slack button, or a Telegram button, because all three mutate the one shared store. See alerts-and-actions.md and security.md.

Policy format

A policy is an array of rules; each rule's when conditions are ANDed, and matching rules contribute their do actions. Actions split into notify (notify_slack/notify_telegram/notify_webhook — dispatched automatically) and control (pause_agent/resume_agent/rollback/throttle/switch_model — which require an approval). Evaluation is a pure function in packages/sdk/src/autopilot/policy.ts.

[
  { "when": { "severity": "high" }, "do": ["notify_slack", "notify_telegram", "pause_agent"] },
  { "when": { "severity": "medium" }, "do": ["notify_slack", "notify_webhook"] },
  { "when": { "tokenSpendDeltaPct": 100 }, "do": ["notify_webhook"] }
]

Model client

Not part of either schema above — deliberately not env-var driven for which provider, only for which model string. There is exactly one file to touch: packages/server/src/config/model-client.ts.

This deployment targets Qwen Cloud (OpenAI-compatible endpoint) via @ai-sdk/openai's createOpenAI factory. Credentials come from .env, never hardcoded:

import { createOpenAI } from '@ai-sdk/openai';
const qwenCloud = createOpenAI({
  baseURL: process.env.QWEN_BASE_URL ?? 'https://dashscope-intl.aliyuncs.com/compatible-mode/v1',
  apiKey: process.env.QWEN_API_KEY ?? '',
});
export const modelClient = qwenCloud(process.env.MODEL ?? 'qwen3.7-max');

Set QWEN_API_KEY (and optionally MODEL) in your .env. To use a different provider, see server.md → Model client.

Any other provider — install exactly that one package, swap two lines:

// pnpm --filter @driftwatch/server add @ai-sdk/anthropic
import { anthropic } from '@ai-sdk/anthropic';
export const modelClient = anthropic(process.env.MODEL ?? 'claude-3-5-sonnet-latest');

Same pattern for @ai-sdk/google or any OpenAI-compatible endpoint (Ollama, vLLM, Together, Groq, DeepSeek, ...) — just change baseURL.

The server calls assertModelClientIsConfigured at startup and refuses to boot without a modelClient — there's no implicit fallback beyond what you put in this file.

Skills (tools)

Also not env-driven — runAgentTask takes tools as a plain parameter. The reference server's demo skills live in packages/server/src/tools.ts (get_weather, search_docs); swap in your own DB lookups, HTTP calls, vector search, following the same tool() + withSkillExecutionSpan pattern so calls still show up in metrics.

Full .env.example

See packages/server/.env.example for every variable above in one file, ready to copy to packages/server/.env.