Load one configuration object at startup, validate it, and fail fast with a clear message when a value is missing. Choose the environment with a variable of your own, such as TEST_ENV, rather than NODE_ENV, which libraries expect to be development, production or test:

import dotenv from 'dotenv';
import { z } from 'zod';

const testEnv = process.env.TEST_ENV ?? 'local';
dotenv.config({ path: `.env.${testEnv}` });

const envSchema = z.object({
  BASE_URL: z.url(),
  API_KEY: z.string().min(1),
  TIMEOUT_MS: z.coerce.number().default(30_000),
});

export const config = envSchema.parse(process.env);

(z.url() is the Zod 4 form; in Zod 3, use z.string().url().)

Keep non-secret settings, such as base URLs and timeouts, in a committed file per environment. Keep secrets out of the repository entirely: in CI, store them in the platform's secret store (GitHub Actions secrets, a cloud secrets manager) and pass them to the job as environment variables, so the same code runs locally and in each pipeline stage. Every stage then runs the same tests, pointed at a different environment.

Sources: Zod 4 changelog, GitHub Actions: using secrets