Configuración

Realice un cambio de configuración y compruébelo

Comience con una aplicación web en ejecución. En el editor abra apps/web/.env.local; si no existe, copie .env.example allí usando el tutorial web. Para una primera comprobación inofensiva, busque EMAIL_PROVIDER=local y déjelo local. Esta configuración envía el correo electrónico del producto a la vista previa local en lugar de a una bandeja de entrada real. No pegue líneas KEY=value en el terminal.

Para cada servicio que habilite, siga la guía de configuración de ese proveedor, reemplace solo los valores nombrados, guarde el archivo, detenga el servidor web con Ctrl + C y reinicie con el siguiente comando. Si la validación identifica una clave que falta, vuelva a abrir este archivo y compare esa clave con la guía del proveedor. Mantenga el archivo raíz .env sincronizado solo para los valores utilizados por las migraciones de bases de datos; copiarlo por sí solo no configura Next.js.

• Buscar una clave de configuración
• Aprenda a ejecutar un comando y editar un archivo

corepack pnpm --filter @supastack/web dev

Los ajustes que realmente editarás primero

.env.example en la raíz del repositorio es el inventario completo de ajustes que el kit entiende; un nombre ausente de ese archivo no existe. Al principio solo tocas unos pocos — el resto permanece en sus valores por defecto hasta que una guía de proveedor los pida.

Qué archivo lee cada app: el .env de la raíz alimenta los comandos de migración, apps/web/.env.local alimenta el servidor Next.js y apps/mobile/.env.local alimenta Expo. Editar un archivo no configura los demás, así que DATABASE_URL vive tanto en el .env de la raíz como en apps/web/.env.local.

• APP_URL — la dirección donde vive la app; http://localhost:3000 en local, tu dominio en producción.
• DATABASE_URL — la cadena de conexión de Postgres que comparten las migraciones y el servidor.
• AUTH_SECRET y CREDENTIAL_ENCRYPTION_KEY — secretos generados; node scripts/setup-env.mjs los rellena por ti (ese helper se incluye en el repositorio web y en el monorepo All Platforms).
• Los selectores de proveedor — EMAIL_PROVIDER, AI_PROVIDER, BILLING_PROVIDER, JOB_PROVIDER, CAPTCHA_PROVIDER — cada uno elige qué adaptador se ejecuta; los valores por defecto local/fake/off no necesitan cuenta.
• Secretos de proveedor como RESEND_API_KEY o STRIPE_SECRET_KEY — añádelos solo cuando la guía del proveedor correspondiente te lo indique.

Empieza con el ejemplo de entorno

El archivo raíz .env.example es el inventario de configuración. La validación compartida está en packages/config. Revisa juntos el entorno de aplicación y los modos de proveedor seleccionados; una interfaz local no constituye una estrategia de credenciales de producción.

El modo de referencia sin credenciales requiere configuración de aplicación local/de prueba y proveedores fake/local. Seleccionar un proveedor de producción cambia los requisitos de runtime.

Mantén los secretos detrás de la API

Los secretos de autenticación, las credenciales de base de datos, las claves de proveedores, los secretos de Stripe y las credenciales de Trigger son solo del servidor. Nunca les añadas el prefijo NEXT_PUBLIC_ o EXPO_PUBLIC_. No los imprimas durante la configuración ni los incluyas en respuestas de error.

El navegador recibe configuración pública y alias de modelos permitidos. La propiedad del espacio de trabajo, las decisiones sobre derechos, los presupuestos y la selección de proveedores se aplican en el servidor.

Comprueba un cambio antes de usarlo

Valida la configuración mediante el paquete de configuración existente y ejecuta las pruebas deterministas pertinentes. Usa la prueba rápida de proveedores independiente y opcional cuando quieras verificar integraciones reales.

corepack pnpm test
corepack pnpm check
corepack pnpm build