The idiomatic way to use ArkEnv in Next.js is the withArkEnv config wrapper. It runs ArkEnv's codegen and validation as part of the Next.js build lifecycle and returns your config object unchanged.
next.config.ts
import { withArkEnv } from "@arkenv/nextjs/config";import type { NextConfig } from "next";const nextConfig: NextConfig = { /* config options here */};export default withArkEnv(nextConfig);
By default, ArkEnv looks for your schema in src/env.ts or env.ts and writes the generated helper to [schemaDirectory]/generated/env.gen.ts.
By default, ArkEnv generates an env.gen.ts helper so you don't have to write a manual runtimeEnv mapping. If you prefer to opt out of codegen entirely, you can. This is useful if you want full control over the runtimeEnv object or are working in an environment where file generation is undesirable.
Pass the --no-codegen flag when bootstrapping with the CLI:
npx @arkenv/cli@latest init --no-codegen
Or set it up manually by passing the { codegen: false } option to withArkEnv in next.config.ts, and importing createEnv directly from @arkenv/nextjs in your schema file. You then become responsible for keeping runtimeEnv in sync with your schema.
[!TIP]
Build-time validation without codegen:
When using { codegen: false }, withArkEnv will skip compiling and generating env.gen.ts but will still execute build-time environment variable validation, ensuring invalid variables fail the build:
next.config.ts
import { withArkEnv } from "@arkenv/nextjs/config";import type { NextConfig } from "next";const nextConfig: NextConfig = {};export default withArkEnv(nextConfig, { codegen: false });
Used to inject public client-side variables dynamically during server-side rendering (SSR), enabling support for runtime environment configuration changes in containerized deployments.