Configuração

Faça uma alteração na configuração e verifique

Comece com um aplicativo Web em execução. No editor abra apps/web/.env.local; se não existir, copie .env.example para lá usando o tutorial da Web. Para uma primeira verificação inofensiva, encontre EMAIL_PROVIDER=local e deixe-o local. Essa configuração envia o e-mail do produto para a visualização local em vez de para uma caixa de entrada real. Não cole linhas KEY=value no terminal.

Para cada serviço habilitado, siga o guia de configuração do provedor, substitua apenas os valores nomeados, salve o arquivo, pare o servidor Web com Ctrl + C e reinicie com o comando abaixo. Se a validação nomear uma chave ausente, reabra esse arquivo e compare essa chave com o guia do provedor. Mantenha root .env sincronizado apenas para valores usados ​​por migrações de banco de dados; copiá-lo sozinho não configura Next.js.

• Procure uma chave de configuração
• Aprenda como executar um comando e editar um arquivo

corepack pnpm --filter @supastack/web dev

As configurações que você vai mesmo editar primeiro

O .env.example na raiz do repositório é o inventário completo das configurações que o kit entende; um nome ausente desse arquivo não existe. No início você só mexe numa pequena parte — o resto fica nos valores padrão até que um guia de provedor peça por eles.

Qual arquivo cada app lê: o .env da raiz alimenta os comandos de migração, apps/web/.env.local alimenta o servidor Next.js e apps/mobile/.env.local alimenta o Expo. Editar um arquivo não configura os outros, por isso DATABASE_URL fica tanto no .env da raiz quanto em apps/web/.env.local.

• APP_URL — o endereço onde o app vive; http://localhost:3000 localmente, o seu domínio em produção.
• DATABASE_URL — a string de conexão Postgres que as migrações e o servidor compartilham.
• AUTH_SECRET e CREDENTIAL_ENCRYPTION_KEY — segredos gerados; node scripts/setup-env.mjs os preenche para você (esse helper vem no repositório Web e no monorepo All Platforms).
• Os seletores de provedor — EMAIL_PROVIDER, AI_PROVIDER, BILLING_PROVIDER, JOB_PROVIDER, CAPTCHA_PROVIDER — cada um escolhe qual adaptador roda; os padrões local/fake/off não precisam de conta.
• Segredos de provedor como RESEND_API_KEY ou STRIPE_SECRET_KEY — adicione-os apenas quando o guia do provedor correspondente mandar.

Começa pelo exemplo de ambiente

O .env.example raiz é o inventário de configuração. A validação partilhada vive em packages/config. Reveja em conjunto o ambiente de aplicação escolhido e os modos de fornecedor; uma interface local não é uma estratégia de credenciais de produção.

O modo de referência sem credenciais exige uma configuração de aplicação local/test e fornecedores fake/locais. Escolher um fornecedor de produção muda os requisitos do runtime.

Mantém os segredos atrás da API

Segredos de auth, credenciais de base, chaves de fornecedor, segredos Stripe e credenciais Trigger são só de servidor. Nunca lhes dês prefixo NEXT_PUBLIC_ ou EXPO_PUBLIC_. Não os mostres durante a instalação nem os incluas em respostas de erro.

O browser recebe configuração pública e aliases de modelo permitidos. Propriedade de workspace, decisões de permissão, orçamentos e escolha de fornecedor ficam aplicados no servidor.

Verifica uma alteração antes de a usar

Valida a configuração através do pacote config existente e corre os testes deterministas relevantes. Usa o caminho de smoke de fornecedor opt-in separado quando estiveres pronto para verificar integrações reais.

corepack pnpm test
corepack pnpm check
corepack pnpm build