Loading and testing environments

Select environment layers explicitly for local commands, workspace members, scripts, and production-shaped tests.

Load environments explicitly

brix dev
brix dev --stage production
brix dev --stage production --no-local
brix dev --no-env
brix test
brix test --env
brix test --stage test --project node
brix build
brix build --stage production --no-local
brix env run test -- run scripts/seed.ts

Development includes local overrides. Ordinary tests and builds are provider-free unless environment loading is requested. Use --no-env only when the environment is already resolved.

Loading order is schema, base, selected stage, local, overrides, then process overrides. --no-local and upload select only schema, base, and stage. There is no implicit root .env, bare .env, or .env.<stage>.local discovery.

In a workspace, select the owning application on the outer command:

brix dev#booking
brix env#booking run test -- run scripts/seed.ts
brix env#booking upload production

Each application owns its schema and generated type; there is no sibling or workspace-root fallback.

Test safely

Keep unit tests independent of secret providers. Supply environment fixtures through the harness without replacing modules or bypassing production validation:

const { testApi } = createTestHarness({
  createApp: () => createBrixApp(brixServer),
  env: { STAGE: "test", CATALOG_URL: "http://catalog.test", CATALOG_TOKEN: "fixture" },
});

Handlers and loaders consume the fixture through c.env, using the same request adapter and parser as production. Use fake values in env/.env.test for offline integration tests and never print resolved configuration. See server setup and Contentful for safe consumption.