t3-env

While you can manually validate process.env using Zod and augment the NodeJS.ProcessEnv interface, T3 Env solves several critical issues:

Transforms and Default values

Manual validation of process.env does not mutate the original object. If you apply transforms (e.g., converting a string to a number), your TypeScript types will reflect the transformed type, but process.env will still contain the original string, leading to type lies. T3 Env provides an object you import that correctly holds both transformed values and default values.

Support for multiple environments

Some frameworks (like Next.js) tree-shake unused environment variables. Simply exporting a validation object might not be enough to ensure variables are included in the bundle. T3 Env uses a Proxy-based implementation to ensure variables are correctly handled across different runtimes.

Client-side safety

Importing a global validation object on the client often causes errors because server-only variables (like DATABASE_URL) are undefined in the browser. T3 Env prevents leaking server variables to the client and provides descriptive error messages when an attempt is made to access a server-only variable in a client context.

Use createEnv from @t3-oss/env-nuxt to define your environment variable schemas. This package is preconfigured for Nuxt and automatically fills the runtimeEnv option.

Supported schema types:

• server: Variables available only on the server side. Accessing these on the client will throw an error.
• client: Variables available on both the client and the server. Note: Client variables must be prefixed with NUXT_PUBLIC_ to avoid type errors.

You can use any Standard Schema compliant validator (e.g., Zod, Valibot, ArkType).

// src/env.ts
import { createEnv } from "@t3-oss/env-nuxt";
import * as z from "zod";

export const env = createEnv({
  /*
   * Serverside Environment variables, not available on the client.
   * Will throw if you access these variables on the client.
   */
  server: {
    DATABASE_URL: z.url(),
    OPEN_AI_API_KEY: z.string().min(1),
  },
  /*
   * Environment variables available on the client (and server).
   *
   * 💡 You'll get type errors if these are not prefixed with NUXT_PUBLIC_.
   */
  client: {
    NUXT_PUBLIC_CLERK_PUBLISHABLE_KEY: z.string().min(1),
  },
});

Use createEnv to define your environment variable schema. You can use any Standard Schema compliant validator (like Zod or Valibot).

• server: Variables available only on the server. Accessing these on the client will throw an error.
• client: Variables available on both client and server. In Next.js, these must be prefixed with NEXT_PUBLIC_.
• runtimeEnv: A mapping of the actual process.env values. You must manually destructure all variables from server and client here to ensure they are included in bundles (especially for Edge or Client runtimes).

// src/env.mjs
import { createEnv } from "@t3-oss/env-nextjs"; // or core package
import * as z from "zod";

export const env = createEnv({
  /*
   * Serverside Environment variables, not available on the client.
   * Will throw if you access these variables on the client.
   */
  server: {
    DATABASE_URL: z.url(),
    OPEN_AI_API_KEY: z.string().min(1),
  },
  /*
   * Environment variables available on the client (and server).
   *
   * 💡 You'll get type errors if these are not prefixed with NEXT_PUBLIC_.
   */
  client: {
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY: z.string().min(1),
  },
  /*
   * Due to how Next.js bundles environment variables on Edge and Client,
   * we need to manually destructure them to make sure all are included in bundle.
   *
   * 💡 You'll get type errors if not all variables from `server` & `client` are included here.
   */
  runtimeEnv: {
    DATABASE_URL: process.env.DATABASE_URL,
    OPEN_AI_API_KEY: process.env.OPEN_AI_API_KEY,
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY:
      process.env.NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY,
  },
});

You can include predefined sets of environment variables (like Vercel or Railway) using the extends property. This is useful for monorepos or deployment-specific variables.

Available Validators

To optimize bundle size, import the preset from the entrypoint matching your validator:

• @t3-oss/env-core/presets-zod
• @t3-oss/env-core/presets-valibot
• @t3-oss/env-core/presets-arktype

Available Presets

• vercel
• neonVercel
• supabaseVercel
• uploadthing
• render
• railway
• fly.io
• netlify
• upstashRedis
• coolify
• vite
• wxt

You can also extend your own custom env objects.

import { createEnv } from "@t3-oss/env-core";
import { vercel } from "@t3-oss/env-core/presets-valibot";
import * as v from "valibot";

export const env = createEnv({
  server: {
    DATABASE_URL: v.pipe(v.string(), v.url()),
  },
  extends: [vercel()],
  runtimeEnv: process.env,
});