onnokh/t3-dot-env-zod
Overview
This skill integrates T3 Env with Zod for Next.js 16+ and Vite projects to validate and type environment variables safely. It focuses on correct client/server separation, framework-aware runtime env handling, and build-time validation. Use it to implement or debug @t3-oss/env-nextjs and @t3-oss/env-core schemas with Zod coercions and presets.
How this skill works
The skill guides you to pick the correct createEnv variant based on your framework (Next.js or Vite) and configures runtimeEnv and clientPrefix accordingly. It inspects your Zod environment schemas for env-safe patterns and recommends strategies like experimental__runtimeEnv for Next.js client vars or import.meta.env for Vite. It also shows where to add build-time validation (for example, importing env in next.config.ts) and how to use presets instead of hand-maintaining platform variables.
When to use it
- Setting up typed env validation for Next.js 16+ projects
- Adding environment validation to Vite apps using import.meta.env
- Debugging @t3-oss/env-nextjs or @t3-oss/env-core schema issues
- Enforcing build-time env validation and runtime separation
- Applying Zod coercions and presets for platform-specific variables
Best practices
- Identify the target framework first and choose the matching createEnv variant
- Keep client vars gated (use experimental__runtimeEnv in Next.js) to avoid accidental server exposure
- Prefer presets for platform variables instead of manually maintaining values
- Use Zod patterns designed for env strings and apply coercions explicitly
- Validate at build-time when supported (import env in build config)
Example use cases
- Next.js 16+ app: use @t3-oss/env-nextjs, enable experimental__runtimeEnv for client-safe keys, validate by importing env in next.config.ts
- Vite app: use @t3-oss/env-core with clientPrefix set to VITE_ and runtimeEnv = import.meta.env
- Migration: convert hand-rolled env checks to Zod schemas with presets and coercions
- Debugging: identify why a variable is missing at runtime by checking build-time validation and client/server separation
FAQ
Use experimental__runtimeEnv when you want a clear client/server split for runtime-exposed variables; it’s recommended for client-only env keys but not required for server-only vars.
How do I validate env at build time?
Import your validated env schema into your build config (for example next.config.ts) so the build fails on invalid or missing variables, ensuring early detection.