Environment variables

Not every value your app needs is a wisp resource — a third-party API key, a database URL for a service you're bringing yourself. wisp treats these as ordinary environment variables, resolved at deploy time.

Referencing one

Just read process.env in your handler, the same way you would in any Node/Bun backend:

export const dbStatus = api.get("/db-status", {}, async () => {
  const configured = Boolean(process.env.DATABASE_URL);
  return { status: 200, body: { databaseConfigured: configured } };
});

At compile time, wisp statically detects every process.env.NAME your handler references — no configuration needed to opt in.

Providing a value

wisp reads the value from your own process's environment at deploy time. Bun already loads .env/.env.local from the current working directory before your code runs, so a project's .env file works the same way it would for any other Bun backend:

DATABASE_URL=postgres://user:pass@host:5432/db

Or export it directly before deploying:

export DATABASE_URL=postgres://user:pass@host:5432/db
wisp deploy

If a referenced variable has no value at deploy time, wisp deploy fails closed — it reports every missing name together, rather than shipping a function that would break on its first real request.

Where the value goes

Each referenced name becomes a CloudFormation Parameter with NoEcho: true — masked in the console, the CLI, and DescribeStacks output. wisp never logs secret values, and this is the mechanism that keeps them out of the synthesized template you can otherwise read in full.