Variáveis de Ambiente

Q: Qual é a ordem de prioridade de carregamento para arquivos .env?

.env.$(NODE_ENV).local (maior prioridade) .env.local .env.$(NODE_ENV) .env (menor prioridade) Arquivos de maior prioridade substituem os de menor. .env.local é ignorado pelo git por padrão.

Q: Como import "server-only" protege segredos em lib/env.ts?

O pacote server-only causa um erro em tempo de compilação se um Componente Cliente importar o módulo. Isso fornece uma garantia rígida de que variáveis de ambiente exclusivas do servidor nunca aparecerão no pacote do navegador.

Q: Como você lida com variáveis de ambiente em tempo de execução em contêineres Docker?

As variáveis NEXT_PUBLIC_ são sempre incorporadas em tempo de compilação e não podem ser alteradas em tempo de execução. As variáveis do lado do servidor devem ser definidas no contêiner em execução (docker run -e KEY=value). Use o modo output: "standalone" para que as leituras de process.env ocorram em tempo de execução para o código do servidor.

Q: Armadilha: Por que .env.local não é carregado durante ambientes test?

O Next.js ignora .env.local quando NODE_ENV=test por padrão. Use .env.test.local em vez disso, ou carregue manualmente os arquivos de ambiente em sua configuração de teste.

Q: Como você tipa variáveis de ambiente em TypeScript para autocompletar?

Isso aumenta a interface global ProcessEnv para que process.env.DATABASE_URL obtenha autocompletar.

Q: Qual vantagem a validação Zod oferece em relação a uma função requireEnv simples?

Zod valida o formato (por exemplo, .url(), .min(32)) e não apenas a presença. Ele fornece inferência de tipo completa, então o objeto retornado é totalmente tipado automaticamente. A validação é executada na inicialização, falhando rapidamente com mensagens de erro claras antes que qualquer solicitação seja atendida.

Q: Armadilha: O que acontece se você usar variáveis NEXT_PUBLIC_ com output: "standalone" no Docker?

Os valores NEXT_PUBLIC_ são substituídos estaticamente em tempo de next build. Definir essas variáveis como variáveis de ambiente em tempo de execução do Docker não tem efeito no código do cliente. Você precisa reconstruir a imagem se algum valor NEXT_PUBLIC_ mudar.

Receita

Configure e use variáveis de ambiente com segurança no Next.js 15+ com arquivos .env, o prefixo NEXT_PUBLIC_ para exposição ao cliente, configuração em tempo de execução e o padrão server-only para evitar vazamento de segredos.

Exemplo de Trabalho

Estrutura do Arquivo .env

# .env.local (ignorado pelo git, substituições locais)
DATABASE_URL="postgresql://user:pass@localhost:5432/mydb"
AUTH_SECRET="super-secret-key-never-expose"
 
# Variáveis seguras para o cliente devem usar o prefixo NEXT_PUBLIC_
NEXT_PUBLIC_APP_URL="http://localhost:3000"
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY="pk_test_abc123"

# .env (verificado no git, padrões compartilhados)
NEXT_PUBLIC_APP_NAME="Meu App"

# .env.production (substituições de produção)
NEXT_PUBLIC_APP_URL="https://myapp.com"

Acesso a Ambiente com Tipagem Segura

// lib/env.ts
import "server-only";
 
function requireEnv(key: string): string {
  const value = process.env[key];
  if (!value) {
    throw new Error(`Variável de ambiente obrigatória não encontrada: ${key}`);
  }
  return value;
}
 
export const env = {
  DATABASE_URL: requireEnv("DATABASE_URL"),
  AUTH_SECRET: requireEnv("AUTH_SECRET"),
} as const;

Acesso a Ambiente Seguro para o Cliente

// lib/env-client.ts
 
export const clientEnv = {
  appUrl: process.env.NEXT_PUBLIC_APP_URL ?? "http://localhost:3000",
  appName: process.env.NEXT_PUBLIC_APP_NAME ?? "Meu App",
  stripeKey: process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY ?? "",
} as const;

Usando Zod para Validação

// lib/env.ts
import "server-only";
import { z } from "zod";
 
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  AUTH_SECRET: z.string().min(32),
  NODE_ENV: z.enum(["development", "production", "test"]),
});
 
export const env = envSchema.parse(process.env);
 
// lib/env-client.ts
const clientEnvSchema = z.object({
  NEXT_PUBLIC_APP_URL: z.string().url(),
  NEXT_PUBLIC_APP_NAME: z.string(),
});
 
export const clientEnv = clientEnvSchema.parse({
  NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL,
  NEXT_PUBLIC_APP_NAME: process.env.NEXT_PUBLIC_APP_NAME,
});

Uso de Componente de Servidor

// app/dashboard/page.tsx
import { env } from "@/lib/env";
 
export default async function DashboardPage() {
  // Seguro: isso é executado apenas no servidor
  const data = await fetch(`${env.DATABASE_URL}/api/data`);
  return <div>{/* renderizar dados */}</div>;
}

Mergulho Profundo

Como Funciona

O Next.js carrega arquivos .env automaticamente na seguinte ordem de prioridade (o maior vence): .env.$(NODE_ENV).local > .env.local > .env.$(NODE_ENV) > .env.
Apenas variáveis prefixadas com NEXT_PUBLIC_ são incluídas no pacote do cliente em tempo de compilação. Todas as outras referências process.env são substituídas por undefined no código do cliente.
process.env não é um objeto real no código do cliente. O Next.js realiza substituição estática de strings em tempo de compilação. Acesso dinâmico como process.env[key] não funcionará em componentes do cliente.
O pacote server-only causa um erro em tempo de compilação se um módulo for importado de um Componente Cliente, fornecendo uma garantia rígida de que os segredos permanecem no servidor.
Variáveis de ambiente são incorporadas em tempo de compilação para páginas estáticas. Para configuração em tempo de execução, use Route Handlers ou serverRuntimeConfig / publicRuntimeConfig em next.config.js (padrão legado do Pages Router).

Variações

Variáveis de Ambiente em Tempo de Execução (Docker):

// next.config.ts
import type { NextConfig } from "next";
 
const nextConfig: NextConfig = {
  // Expõe variáveis de ambiente do lado do servidor em tempo de execução (não em tempo de compilação)
  serverRuntimeConfig: {
    databaseUrl: process.env.DATABASE_URL,
  },
  // Expõe para servidor e cliente em tempo de execução
  publicRuntimeConfig: {
    apiUrl: process.env.NEXT_PUBLIC_API_URL,
  },
};
 
export default nextConfig;

Usando T3 Env para Validação Completa:

// env.mjs
import { createEnv } from "@t3-oss/env-nextjs";
import { z } from "zod";
 
export const env = createEnv({
  server: {
    DATABASE_URL: z.string().url(),
    AUTH_SECRET: z.string().min(1),
  },
  client: {
    NEXT_PUBLIC_APP_URL: z.string().url(),
  },
  runtimeEnv: {
    DATABASE_URL: process.env.DATABASE_URL,
    AUTH_SECRET: process.env.AUTH_SECRET,
    NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL,
  },
});

Notas TypeScript

Crie um env.d.ts para aumentar ProcessEnv para autocompletar:

// env.d.ts
declare namespace NodeJS {
  interface ProcessEnv {
    DATABASE_URL: string;
    AUTH_SECRET: string;
    NEXT_PUBLIC_APP_URL: string;
    NEXT_PUBLIC_APP_NAME: string;
  }
}

Objetos de ambiente validados por Zod fornecem inferência de tipo completa sem anotações de tipo adicionais.

Armadilhas

Acesso dinâmico a propriedades não funciona em código do cliente. process.env[varName] será sempre undefined no cliente porque o Next.js realiza substituição estática de strings, não consulta em tempo de execução.
.env.local não é carregado em ambientes test por padrão. Use um arquivo .env.test.local ou carregue as variáveis de ambiente manualmente na configuração de seus testes.
Alterar arquivos .env requer reinicialização do servidor de desenvolvimento. O hot reload não capta as alterações nas variáveis de ambiente.
Valores NEXT_PUBLIC_ são visíveis no pacote do navegador. Nunca coloque segredos (chaves de API, URLs de banco de dados, segredos de autenticação) atrás deste prefixo.
Builds do Docker incorporam variáveis de ambiente em tempo de compilação. Para variáveis de ambiente em tempo de execução em contêineres, use o modo de saída standalone e defina as variáveis de ambiente no contêiner em execução, não na etapa RUN do Dockerfile.

Alternativas

Abordagem	Prós	Contras
Arquivos `.env` com `NEXT_PUBLIC_`	Embutido, sem configuração	Sem validação, sem env em tempo de execução
Validação Zod em `lib/env.ts`	Seguro em tipo, falha rápido	Configuração manual
T3 Env (`@t3-oss/env-nextjs`)	Validação completa, divisão cliente/servidor	Dependência extra
`next.config.js` runtimeConfig	Verdadeiro env em tempo de execução	Padrão legado, não nativo do App Router
Env da Plataforma (Vercel, AWS)	Seguro, por ambiente	Configuração específica do fornecedor

FAQs

Por que `process.env[varName]` retorna `undefined` em código do cliente?

O Next.js realiza substituição estática de strings em tempo de compilação, não consulta em tempo de execução.
Apenas referências literais como process.env.NEXT_PUBLIC_APP_URL são substituídas.
O acesso dinâmico a propriedades (por exemplo, process.env[key]) não pode ser resolvido em tempo de compilação e retorna undefined.

Qual é a ordem de prioridade de carregamento para arquivos `.env`?

.env.$(NODE_ENV).local (maior prioridade)
.env.local
.env.$(NODE_ENV)
.env (menor prioridade)
Arquivos de maior prioridade substituem os de menor. .env.local é ignorado pelo git por padrão.

O que acontece se você colocar um segredo (como uma URL de banco de dados) atrás do prefixo `NEXT_PUBLIC_`?

O valor é incluído no pacote JavaScript do lado do cliente em tempo de compilação.
Qualquer pessoa que inspecionar o código-fonte do navegador ou o pacote poderá ver o segredo.
Nunca coloque chaves de API, URLs de banco de dados ou segredos de autenticação atrás de NEXT_PUBLIC_.

Por que alterar um arquivo `.env` requer uma reinicialização do servidor?

As variáveis de ambiente são carregadas uma vez quando o servidor de desenvolvimento é iniciado.
A substituição de módulo a quente (HMR) não relê os arquivos .env.
Você deve parar e reiniciar next dev para que as alterações entrem em vigor.

Como `import "server-only"` protege segredos em `lib/env.ts`?

O pacote server-only causa um erro em tempo de compilação se um Componente Cliente importar o módulo.
Isso fornece uma garantia rígida de que variáveis de ambiente exclusivas do servidor nunca aparecerão no pacote do navegador.

Como você lida com variáveis de ambiente em tempo de execução em contêineres Docker?

As variáveis NEXT_PUBLIC_ são sempre incorporadas em tempo de compilação e não podem ser alteradas em tempo de execução.
As variáveis do lado do servidor devem ser definidas no contêiner em execução (docker run -e KEY=value).
Use o modo output: "standalone" para que as leituras de process.env ocorram em tempo de execução para o código do servidor.

Armadilha: Por que `.env.local` não é carregado durante ambientes `test`?

O Next.js ignora .env.local quando NODE_ENV=test por padrão.
Use .env.test.local em vez disso, ou carregue manualmente os arquivos de ambiente em sua configuração de teste.

Como você tipa variáveis de ambiente em TypeScript para autocompletar?

// env.d.ts
declare namespace NodeJS {
  interface ProcessEnv {
    DATABASE_URL: string;
    AUTH_SECRET: string;
    NEXT_PUBLIC_APP_URL: string;
  }
}

Isso aumenta a interface global ProcessEnv para que process.env.DATABASE_URL obtenha autocompletar.

Qual vantagem a validação Zod oferece em relação a uma função `requireEnv` simples?

Zod valida o formato (por exemplo, .url(), .min(32)) e não apenas a presença.
Ele fornece inferência de tipo completa, então o objeto retornado é totalmente tipado automaticamente.
A validação é executada na inicialização, falhando rapidamente com mensagens de erro claras antes que qualquer solicitação seja atendida.

Armadilha: O que acontece se você usar variáveis `NEXT_PUBLIC_` com `output: "standalone"` no Docker?

Os valores NEXT_PUBLIC_ são substituídos estaticamente em tempo de next build.
Definir essas variáveis como variáveis de ambiente em tempo de execução do Docker não tem efeito no código do cliente.
Você precisa reconstruir a imagem se algum valor NEXT_PUBLIC_ mudar.

O que é T3 Env e como ele difere de uma configuração Zod manual?

T3 Env (@t3-oss/env-nextjs) fornece uma única chamada createEnv que separa esquemas de servidor e cliente.
Ele valida automaticamente que as variáveis NEXT_PUBLIC_ estão na seção client e as variáveis do servidor estão em server.
Uma configuração Zod manual requer que você lide com a divisão cliente/servidor por conta própria.

Como você tiparia o valor de retorno de um objeto de ambiente validado por Zod em TypeScript?

import { z } from "zod";
 
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  AUTH_SECRET: z.string().min(32),
});
 
// O tipo é inferido automaticamente:
// { DATABASE_URL: string; AUTH_SECRET: string }
export const env = envSchema.parse(process.env);

Nenhuma anotação de tipo manual é necessária; Zod infere o tipo do esquema.

Relacionados

Autenticação - armazenando AUTH_SECRET com segurança
Implantação - variáveis de ambiente no Docker e produção
Manipuladores de Rota de API - acessando variáveis de ambiente em Manipuladores de Rota
Documentação de Variáveis de Ambiente do Next.js

Receita

Exemplo de Trabalho

Estrutura do Arquivo .env

# .env.local (ignorado pelo git, substituições locais)
DATABASE_URL="postgresql://user:pass@localhost:5432/mydb"
AUTH_SECRET="super-secret-key-never-expose"
 
# Variáveis seguras para o cliente devem usar o prefixo NEXT_PUBLIC_
NEXT_PUBLIC_APP_URL="http://localhost:3000"
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY="pk_test_abc123"

# .env (verificado no git, padrões compartilhados)
NEXT_PUBLIC_APP_NAME="Meu App"

# .env.production (substituições de produção)
NEXT_PUBLIC_APP_URL="https://myapp.com"

Acesso a Ambiente com Tipagem Segura

// lib/env.ts
import "server-only";
 
function requireEnv(key: string): string {
  const value = process.env[key];
  if (!value) {
    throw new Error(`Variável de ambiente obrigatória não encontrada: ${key}`);
  }
  return value;
}
 
export const env = {
  DATABASE_URL: requireEnv("DATABASE_URL"),
  AUTH_SECRET: requireEnv("AUTH_SECRET"),
} as const;

Acesso a Ambiente Seguro para o Cliente

// lib/env-client.ts
 
export const clientEnv = {
  appUrl: process.env.NEXT_PUBLIC_APP_URL ?? "http://localhost:3000",
  appName: process.env.NEXT_PUBLIC_APP_NAME ?? "Meu App",
  stripeKey: process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY ?? "",
} as const;

Usando Zod para Validação

// lib/env.ts
import "server-only";
import { z } from "zod";
 
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  AUTH_SECRET: z.string().min(32),
  NODE_ENV: z.enum(["development", "production", "test"]),
});
 
export const env = envSchema.parse(process.env);
 
// lib/env-client.ts
const clientEnvSchema = z.object({
  NEXT_PUBLIC_APP_URL: z.string().url(),
  NEXT_PUBLIC_APP_NAME: z.string(),
});
 
export const clientEnv = clientEnvSchema.parse({
  NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL,
  NEXT_PUBLIC_APP_NAME: process.env.NEXT_PUBLIC_APP_NAME,
});

Uso de Componente de Servidor

// app/dashboard/page.tsx
import { env } from "@/lib/env";
 
export default async function DashboardPage() {
  // Seguro: isso é executado apenas no servidor
  const data = await fetch(`${env.DATABASE_URL}/api/data`);
  return <div>{/* renderizar dados */}</div>;
}

Mergulho Profundo

Como Funciona

O Next.js carrega arquivos .env automaticamente na seguinte ordem de prioridade (o maior vence): .env.$(NODE_ENV).local > .env.local > .env.$(NODE_ENV) > .env.
Apenas variáveis prefixadas com NEXT_PUBLIC_ são incluídas no pacote do cliente em tempo de compilação. Todas as outras referências process.env são substituídas por undefined no código do cliente.
process.env não é um objeto real no código do cliente. O Next.js realiza substituição estática de strings em tempo de compilação. Acesso dinâmico como process.env[key] não funcionará em componentes do cliente.
O pacote server-only causa um erro em tempo de compilação se um módulo for importado de um Componente Cliente, fornecendo uma garantia rígida de que os segredos permanecem no servidor.
Variáveis de ambiente são incorporadas em tempo de compilação para páginas estáticas. Para configuração em tempo de execução, use Route Handlers ou serverRuntimeConfig / publicRuntimeConfig em next.config.js (padrão legado do Pages Router).

Variações

Variáveis de Ambiente em Tempo de Execução (Docker):

// next.config.ts
import type { NextConfig } from "next";
 
const nextConfig: NextConfig = {
  // Expõe variáveis de ambiente do lado do servidor em tempo de execução (não em tempo de compilação)
  serverRuntimeConfig: {
    databaseUrl: process.env.DATABASE_URL,
  },
  // Expõe para servidor e cliente em tempo de execução
  publicRuntimeConfig: {
    apiUrl: process.env.NEXT_PUBLIC_API_URL,
  },
};
 
export default nextConfig;

Usando T3 Env para Validação Completa:

// env.mjs
import { createEnv } from "@t3-oss/env-nextjs";
import { z } from "zod";
 
export const env = createEnv({
  server: {
    DATABASE_URL: z.string().url(),
    AUTH_SECRET: z.string().min(1),
  },
  client: {
    NEXT_PUBLIC_APP_URL: z.string().url(),
  },
  runtimeEnv: {
    DATABASE_URL: process.env.DATABASE_URL,
    AUTH_SECRET: process.env.AUTH_SECRET,
    NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL,
  },
});

Notas TypeScript

Crie um env.d.ts para aumentar ProcessEnv para autocompletar:

// env.d.ts
declare namespace NodeJS {
  interface ProcessEnv {
    DATABASE_URL: string;
    AUTH_SECRET: string;
    NEXT_PUBLIC_APP_URL: string;
    NEXT_PUBLIC_APP_NAME: string;
  }
}

Objetos de ambiente validados por Zod fornecem inferência de tipo completa sem anotações de tipo adicionais.

Armadilhas

Acesso dinâmico a propriedades não funciona em código do cliente. process.env[varName] será sempre undefined no cliente porque o Next.js realiza substituição estática de strings, não consulta em tempo de execução.
.env.local não é carregado em ambientes test por padrão. Use um arquivo .env.test.local ou carregue as variáveis de ambiente manualmente na configuração de seus testes.
Alterar arquivos .env requer reinicialização do servidor de desenvolvimento. O hot reload não capta as alterações nas variáveis de ambiente.
Valores NEXT_PUBLIC_ são visíveis no pacote do navegador. Nunca coloque segredos (chaves de API, URLs de banco de dados, segredos de autenticação) atrás deste prefixo.
Builds do Docker incorporam variáveis de ambiente em tempo de compilação. Para variáveis de ambiente em tempo de execução em contêineres, use o modo de saída standalone e defina as variáveis de ambiente no contêiner em execução, não na etapa RUN do Dockerfile.

Alternativas

Abordagem	Prós	Contras
Arquivos `.env` com `NEXT_PUBLIC_`	Embutido, sem configuração	Sem validação, sem env em tempo de execução
Validação Zod em `lib/env.ts`	Seguro em tipo, falha rápido	Configuração manual
T3 Env (`@t3-oss/env-nextjs`)	Validação completa, divisão cliente/servidor	Dependência extra
`next.config.js` runtimeConfig	Verdadeiro env em tempo de execução	Padrão legado, não nativo do App Router
Env da Plataforma (Vercel, AWS)	Seguro, por ambiente	Configuração específica do fornecedor

FAQs

Por que `process.env[varName]` retorna `undefined` em código do cliente?

O Next.js realiza substituição estática de strings em tempo de compilação, não consulta em tempo de execução.
Apenas referências literais como process.env.NEXT_PUBLIC_APP_URL são substituídas.
O acesso dinâmico a propriedades (por exemplo, process.env[key]) não pode ser resolvido em tempo de compilação e retorna undefined.

Qual é a ordem de prioridade de carregamento para arquivos `.env`?

.env.$(NODE_ENV).local (maior prioridade)
.env.local
.env.$(NODE_ENV)
.env (menor prioridade)
Arquivos de maior prioridade substituem os de menor. .env.local é ignorado pelo git por padrão.

O que acontece se você colocar um segredo (como uma URL de banco de dados) atrás do prefixo `NEXT_PUBLIC_`?

O valor é incluído no pacote JavaScript do lado do cliente em tempo de compilação.
Qualquer pessoa que inspecionar o código-fonte do navegador ou o pacote poderá ver o segredo.
Nunca coloque chaves de API, URLs de banco de dados ou segredos de autenticação atrás de NEXT_PUBLIC_.

Por que alterar um arquivo `.env` requer uma reinicialização do servidor?

As variáveis de ambiente são carregadas uma vez quando o servidor de desenvolvimento é iniciado.
A substituição de módulo a quente (HMR) não relê os arquivos .env.
Você deve parar e reiniciar next dev para que as alterações entrem em vigor.

Como `import "server-only"` protege segredos em `lib/env.ts`?

O pacote server-only causa um erro em tempo de compilação se um Componente Cliente importar o módulo.
Isso fornece uma garantia rígida de que variáveis de ambiente exclusivas do servidor nunca aparecerão no pacote do navegador.

Como você lida com variáveis de ambiente em tempo de execução em contêineres Docker?

As variáveis NEXT_PUBLIC_ são sempre incorporadas em tempo de compilação e não podem ser alteradas em tempo de execução.
As variáveis do lado do servidor devem ser definidas no contêiner em execução (docker run -e KEY=value).
Use o modo output: "standalone" para que as leituras de process.env ocorram em tempo de execução para o código do servidor.

Armadilha: Por que `.env.local` não é carregado durante ambientes `test`?

O Next.js ignora .env.local quando NODE_ENV=test por padrão.
Use .env.test.local em vez disso, ou carregue manualmente os arquivos de ambiente em sua configuração de teste.

Como você tipa variáveis de ambiente em TypeScript para autocompletar?

// env.d.ts
declare namespace NodeJS {
  interface ProcessEnv {
    DATABASE_URL: string;
    AUTH_SECRET: string;
    NEXT_PUBLIC_APP_URL: string;
  }
}

Isso aumenta a interface global ProcessEnv para que process.env.DATABASE_URL obtenha autocompletar.

Qual vantagem a validação Zod oferece em relação a uma função `requireEnv` simples?

Zod valida o formato (por exemplo, .url(), .min(32)) e não apenas a presença.
Ele fornece inferência de tipo completa, então o objeto retornado é totalmente tipado automaticamente.
A validação é executada na inicialização, falhando rapidamente com mensagens de erro claras antes que qualquer solicitação seja atendida.

Armadilha: O que acontece se você usar variáveis `NEXT_PUBLIC_` com `output: "standalone"` no Docker?

Os valores NEXT_PUBLIC_ são substituídos estaticamente em tempo de next build.
Definir essas variáveis como variáveis de ambiente em tempo de execução do Docker não tem efeito no código do cliente.
Você precisa reconstruir a imagem se algum valor NEXT_PUBLIC_ mudar.

O que é T3 Env e como ele difere de uma configuração Zod manual?

T3 Env (@t3-oss/env-nextjs) fornece uma única chamada createEnv que separa esquemas de servidor e cliente.
Ele valida automaticamente que as variáveis NEXT_PUBLIC_ estão na seção client e as variáveis do servidor estão em server.
Uma configuração Zod manual requer que você lide com a divisão cliente/servidor por conta própria.

Como você tiparia o valor de retorno de um objeto de ambiente validado por Zod em TypeScript?

import { z } from "zod";
 
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  AUTH_SECRET: z.string().min(32),
});
 
// O tipo é inferido automaticamente:
// { DATABASE_URL: string; AUTH_SECRET: string }
export const env = envSchema.parse(process.env);

Nenhuma anotação de tipo manual é necessária; Zod infere o tipo do esquema.

Relacionados

Autenticação - armazenando AUTH_SECRET com segurança
Implantação - variáveis de ambiente no Docker e produção
Manipuladores de Rota de API - acessando variáveis de ambiente em Manipuladores de Rota
Documentação de Variáveis de Ambiente do Next.js

Variáveis de Ambiente

Buscar na documentação

Variáveis de Ambiente