Variables de entorno en producción

Dónde configurar las variables del Backend y del Frontend cuando despliegas en producción (por ejemplo con Docker en tu servidor).

---

Resumen rápido

Dónde	Archivo / Lugar	Cuándo se usan
Backend	Backend/.env	En cada arranque del contenedor (o proceso Node).
Frontend	Variables de entorno en el servidor (o .env en la raíz) antes del build	Solo en el momento del build de la imagen Docker del frontend.

---

1. Backend — Backend/.env

Todas las variables del API se configuran en un solo archivo en el servidor:

Backend/.env

Ese archivo lo usa Docker Compose (env_file: ./Backend/.env) para inyectar las variables en el contenedor del backend. No copies variables del backend a la raíz del repo ni al frontend.

Cómo crearlo en producción

1. En el servidor, dentro del repositorio (por ejemplo /var/www/abaco o donde tengas el proyecto):

   cp Backend/.env.example Backend/.env

2. Edita Backend/.env y rellena los valores de producción, por ejemplo:

# --- Base de datos (MySQL en el servidor) ---
DB_NAME=abaco_prod
DB_USER=abaco_user
DB_PASSWORD=tu_password_seguro
DB_HOST=host.docker.internal
DB_DIALECT=mysql

# --- Servidor ---
PORT=3000
NODE_ENV=production
FRONTEND_URL=https://abaco.hn

# Cookies: dominio para que el navegador envíe cookies a abaco.hn y api.abaco.hn
COOKIE_DOMAIN=.abaco.hn

# --- Autenticación ---
JWT_SECRET=un_secret_largo_y_aleatorio
SESSION_SECRET=otro_secret_largo_y_aleatorio

# --- Redis (contenedor del mismo compose) ---
REDIS_HOST=redis
REDIS_PORT=6379

# --- AWS (S3, SES, etc.) ---
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
AWS_REGION=us-east-1
AWS_S3_BUCKET_NAME=...
SES_EMAIL_SOURCE=...

# --- OAuth Google / Microsoft (Gmail, Outlook, login) ---
GOOGLE_CLIENT_ID=...
GOOGLE_CLIENT_SECRET=...
GOOGLE_CALLBACK_URL=https://api.abaco.hn/auth/google/callback
MICROSOFT_CLIENT_ID=...
MICROSOFT_CLIENT_SECRET=...
MICROSOFT_CALLBACK_URL=https://api.abaco.hn/auth/microsoft/callback
API_URL=https://api.abaco.hn

# --- reCAPTCHA ---
RECAPTCHA_SECRET_KEY=...

# --- IA, BCH, N1CO, etc. (según uses) ---
# Ver Backend/.env.example para la lista completa

• Importante: Backend/.env no debe subirse a Git (ya está en .gitignore). En el servidor lo creas/copias tú y lo mantienes seguro.

---

2. Frontend — variables en tiempo de build

El frontend (Next.js) usa variables que empiezan por NEXT_PUBLIC_. Esas se “queman” en el build: el valor que exista en el momento de construir la imagen es el que verá el navegador. No se leen en tiempo de ejecución desde un .env dentro del contenedor.

Variables que usa el frontend

• NEXT_PUBLIC_API_BASE_URL — URL pública del API (la que usa el navegador). En producción suele ser algo como https://api.abaco.hn.
• NEXT_PUBLIC_RECAPTCHA_SITE_KEY — (Opcional) Clave “site” de reCAPTCHA para el formulario de login/registro.

Dónde configurarlas en producción

Con el override de producción (docker-compose.prod.yml), el build del frontend toma esas variables del entorno del shell donde ejecutas docker compose. Tienes dos formas de definirlas:

Opción A — Archivo .env en la raíz del proyecto (recomendado)

En el mismo nivel que docker-compose.yml (raíz del repo), crea o edita .env:

# En el servidor, en la raíz del repo (donde está docker-compose.yml)
nano .env

Contenido mínimo:

NEXT_PUBLIC_API_BASE_URL=https://api.abaco.hn
NEXT_PUBLIC_RECAPTCHA_SITE_KEY=6LfjQosqAAAAAIxw-EAYFkHXTrccX6zfT2nK9wCq

Docker Compose lee automáticamente el .env de la raíz y pasa ${NEXT_PUBLIC_API_BASE_URL} y ${NEXT_PUBLIC_RECAPTCHA_SITE_KEY} como argumentos de build al Dockerfile del frontend.

Opción B — Exportar en el shell antes del build

export NEXT_PUBLIC_API_BASE_URL=https://api.abaco.hn
export NEXT_PUBLIC_RECAPTCHA_SITE_KEY=tu_site_key
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build

Comando de producción

Siempre que construyas/levantes en producción, usa el override para que el frontend se construya con la URL correcta del API:

docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build

Si NEXT_PUBLIC_API_BASE_URL no está definida, el compose fallará con un mensaje que pide definirla (así se evita construir con la URL por defecto de desarrollo).

---

3. Resumen por entorno

Variable / Archivo	Dónde se configura en producción
DB_, PORT, JWT_, AWS_*, FRONTEND_URL, COOKIE_DOMAIN, OAuth, Redis, etc.	Backend/.env
NEXT_PUBLIC_API_BASE_URL	Raíz del repo: .env (o export antes del build)
NEXT_PUBLIC_RECAPTCHA_SITE_KEY	Raíz del repo: .env (o export)

---

4. Comprobar que todo está bien

• Backend: Tras docker compose ... up, revisa logs del contenedor abaco-backend y que no haya errores de DB_HOST, JWT_SECRET, etc. La app debe conectar a MySQL y Redis.
• Frontend: Abre https://abaco.hn en el navegador; si el login o las peticiones al API fallan por CORS o 404, revisa:
  • Que NEXT_PUBLIC_API_BASE_URL sea exactamente la URL que usa el navegador para el API (ej. https://api.abaco.hn).
  • Que en Backend/.env tengas FRONTEND_URL=https://abaco.hn y, si aplica, CORS_ORIGINS vacío o con los orígenes correctos (en docker-compose.prod.yml se deja vacío para usar la lógica de producción del backend).
• Cookies: Si el frontend está en https://abaco.hn y el API en https://api.abaco.hn, en Backend/.env debe estar COOKIE_DOMAIN=.abaco.hn para que las cookies de sesión se envíen a ambos subdominios.

Si quieres, en el siguiente paso podemos revisar un checklist de despliegue (HTTPS, nginx, dominios) usando estos mismos archivos.