Ambiente: Producción

Status: ⏳ No provisionado todavía — dominios decididos/previstos (2026-07-28), infraestructura pendiente. Última actualización: 2026-08-07

Sigue en AWS. El ADR-006 planteaba construir producción directo en Azure; esa migración se descartó el 2026-08-07 (ver ADR-006). El Terraform de infra/terraform/environments/production/ es el que vale — y desde el 2026-08-07 además planea: hasta ese día tenía un error que lo hacía fallar (al módulo github_oidc le faltaban dos argumentos requeridos), invisible porque nunca se había corrido terraform validate con el binario real.

Qué falta para provisionar Producción

• [ ] Proyecto Firebase de Producción (Hosting + Authentication), separado de Dev/Staging.
• [ ] Credenciales de producción de Soterex (Guatemala, y luego el resto de los países vía ABM de Países).
• [ ] Backend desplegado con monitoreo/observabilidad (Architect + DevOps).
• [ ] Base de datos de Producción con backups configurados.
• [ ] Certificado ACM para el ALB del backend — cubre únicamente api.soterex.cislatam.net (un solo dominio exacto, sin wildcard: docs.*/docs.api.* van por Firebase Hosting, con TLS automático propio, no pasan por este ALB). Ver infra/terraform/environments/production/variables.tf (acm_certificate_arn) y el runbook de Staging (doc/plans/2026-07-25-staging-go-live-runbook.md) como referencia del mismo procedimiento.
• [ ] Templating por ambiente de la config de Firebase en doc/site/public/. Sigue pendiente, aunque cambió de forma: los literales "REEMPLAZAR" se reemplazaron el 2026-07-28 por la config real, pero hardcodeada a soterex-staging. Deployado tal cual en producción, el portal autenticaría contra el proyecto de staging. (No es un secreto filtrado: una config de cliente de Firebase es pública por diseño.) El job deploy-docs-api de .github/workflows/deploy-staging.yml deploya doc/site/public tal cual, sin build ni inyección de variables, así que no lo resuelve. Opciones: envsubst en el entrypoint de nginx, build por ambiente en CI, o un config.json externo fetcheado antes de initializeApp.
• [ ] Volver a poner production en la matriz de .github/workflows/terraform-plan.yml. Se sacó el 2026-08-07 porque el rol de IAM que ese workflow asume por OIDC lo crea el propio terraform apply de producción: hasta el primer apply no hay rol que asumir, así que planear producción falla siempre — un rojo permanente que no señala ningún problema real. Después del primer apply, el plan sí es señal útil.
• [ ] Crear el GitHub Environment production (con reviewers obligatorios). Los jobs que asumen un rol por OIDC tienen que declarar environment:, porque la trust policy exige que el claim sub termine en :environment:production — sin esa línea GitHub no emite el claim y AWS rechaza el AssumeRole. Es el mismo error que tuvo terraform-plan.yml con staging hasta el 2026-08-09.
• [ ] Revisión de security (JWT, manejo de credenciales de Soterex, timeout de sesión, logs de auditoría) antes del primer deploy.
• [ ] Runbook de incidentes (tech-writer + devops).

URL(s)

Dominios decididos/previstos (2026-07-28) — mismo patrón que Staging (doc/plans/2026-07-25-staging-go-live-runbook.md), sin el segmento stag. El de la web app principal es el único a confirmar cuando llegue el momento (el runbook lo deja explícito así), los otros 3 ya están en uso real en el esquema de Staging:

Componente	URL Producción	Estado
Web app principal	https://soterex.cislatam.net (a confirmar)	⏳
Backend / API propia (donde Soterex se conecta, ej. webhook — ver Pregunta Abierta #2b del Análisis Funcional)	https://api.soterex.cislatam.net	⏳ dominio decidido, no provisionado
Documentación funcional (VitePress)	https://docs.soterex.cislatam.net	⏳ dominio decidido, no provisionado
Referencia de API (Scalar)	https://docs.api.soterex.cislatam.net	⏳ dominio decidido, no provisionado

Checklist de go-live

• [ ] Todas las Preguntas Abiertas bloqueantes del Análisis Funcional resueltas (doc/functional/2026-07-24-soterex-integracion/06-preguntas-abiertas.md).
• [ ] ADRs de arquitectura aprobados (doc/architecture/).
• [ ] Revisión de seguridad completa.
• [ ] Prueba end-to-end con Soterex en sandbox exitosa antes de pasar a credenciales reales.

Notas

Ninguna decisión de producción se toma en este documento sin que exista antes su ADR correspondiente en doc/architecture/.