Typesafe Env Generator

T3-env (@t3-oss/env-core, @t3-oss/env-nextjs) is a TypeScript library that validates environment variables at build/runtime using Zod schemas. It provides type-safe access to env vars, catches missing or malformed variables early (at startup, not runtime), and separates server-side from client-side env vars.

Missing or malformed env vars are a common source of runtime errors that are hard to debug. Without validation, your app might silently use undefined values or crash with cryptic errors. Zod validation catches these issues at startup with clear error messages, and TypeScript types prevent typos in variable names throughout your codebase.

Plain Zod: you call z.object().parse(process.env) yourself, which works but requires manual setup for server/client separation and Next.js compatibility. T3-env: wraps Zod with a createEnv() helper that handles Next.js client prefix rules (NEXT_PUBLIC_), build-time validation, and TypeScript intellisense — less boilerplate for Next.js projects.

With @t3-oss/env-nextjs: create env.ts with createEnv({ server: {...}, client: {...}, runtimeEnv: process.env }). Import and use env.DATABASE_URL instead of process.env.DATABASE_URL. Client vars must be prefixed with NEXT_PUBLIC_. The schema runs at build time, so missing vars fail the build rather than failing at runtime.

z.string() for most values. z.string().url() for URLs. z.string().email() for emails. z.coerce.number() for numeric values (coerces the string from process.env to a number). z.enum(['true','false']).transform(v => v === 'true') or z.string().transform(v => v === 'true') for booleans. All env vars start as strings, so use z.coerce for numbers.

Yes. Use @t3-oss/env-core for framework-agnostic usage. The API is the same — createEnv({ server: {...}, runtimeEnv: process.env }) — but without Next.js-specific client prefix handling. Works with any Node.js, Bun, or Deno project.