Environment variables
Dusk reads one thing from the environment at run time: the variables your defineEnv schema names, from process.env, validated when the server entry is imported (see…
Dusk reads one thing from the environment at run time: the variables your defineEnv schema names, from process.env,
validated when the server entry is imported (see Environment variables).
A missing or invalid value makes import "./dist/server/entry.js" throw an EnvError that lists the names and never
the values, so the process exits before it listens and the orchestrator shows a failed start instead of a half-working
server. Everything else is yours: PORT and HOST mean what serve.mjs makes them mean. NODE_ENV changes nothing
in the built server entry, which is created with dev: false (the full contract is in NODE_ENV).
DUSK_PUBLIC_* variables are different: Vite inlines them into the client bundle when dusk build runs, so they must exist
in the build environment, and changing one means building again.
Edge runtimes: where the variables come from#
Edge entries have no process.env of their own, so the generated entry passes runtimeEnvironment() as the environment
of each request. It reads Deno.env.toObject() when the Deno global has one, and process.env otherwise; the values
are strings, and a name the platform does not set is absent (not undefined). The Netlify edge entry
(edge-functions/render.mjs) also passes the Netlify context, so waitUntil is the platform's, and the client address comes
from x-nf-client-connection-ip.