Aula interactiva · Clase 7Público
URL del sitio, identificadores de contenido y claves diseñadas para frontend bajo RLS.
Clase 7 · De demo a producto II
Publica sin convertir el lanzamiento en un acto de fe.
Montamos OmniMarket en un VPS, conectamos dominio y HTTPS, separamos secretos, desplegamos con backup y rollback y validamos el recorrido completo desde el navegador hasta la base y la automatización.
VPSDominio + HTTPSDeploy atómicoObservabilidad + rollback
De localhost a Internet
Cada capa responde una pregunta diferente.
Dominio y DNS
¿Qué nombre público apunta a qué servidor?
DirecciónHTTPS / TLS
¿La conexión cifra el tráfico y valida el destino?
ConfianzaReverse proxy
¿Qué servicio recibe cada host o ruta?
EnrutamientoVPS
¿Qué máquina ejecuta aplicación, n8n y servicios?
CómputoContenedores / procesos
¿Cómo se aíslan, arrancan y actualizan los componentes?
EjecuciónLogs y métricas
¿Cómo sabemos qué pasó y dónde falló?
EvidenciaTres ambientes
Producción no debería ser el primer lugar donde pruebas.
| Ambiente | Objetivo | Datos | Acciones externas |
|---|---|---|---|
| Local | Construir y depurar rápido. | Ficticios o anonimizados. | Simuladas o cerradas. |
| Staging | Probar arquitectura y recorrido parecido a producción. | Semilla controlada. | Proveedores sandbox o destinatarios de prueba. |
| Producción | Servir usuarios reales con operación observable. | Reales y gobernados. | Sólo después de gates, límites y reconciliación. |
Topología OmniMarket
Una ruta pública; servicios privados detrás.
UsuarioNavegador y horario local.
→DNS + HTTPSDominio válido y tráfico cifrado.
→ProxyEnvía cada host a su servicio.
→App / SupabaseUI, Auth, API y Postgres.
↔n8nJobs internos y proveedores.
Principio: no publiques Postgres directamente en Internet porque sea más fácil. La app y n8n usan rutas y credenciales acotadas; el acceso administrativo queda restringido.
Secretos y configuración
El código dice cómo; el entorno decide con qué.
Privado
Service role, contraseña de base, llaves SMTP, SSH y tokens administrativos.
Versionado
Plantillas de variables y nombres, nunca los valores reales.
Rotación
Dueño, vencimiento, revocación y procedimiento si una clave se expone.
Prueba rápida: si una credencial aparece en HTML, bundle JavaScript, captura, documento del curso o evento de Analytics, asume exposición y rótala.
Despliegue como transacción
Preparar, cambiar, verificar o volver atrás.
Congelar la versiónCommit o artefacto exacto, dependencias y migraciones conocidas.
Validar antesBuild, pruebas, medición, configuración y estado del destino.
Crear backupArchivos, base y configuración que realmente permiten restaurar.
Subir a staging privadoChecksums y estructura completa antes de cambiar tráfico.
Swap atómicoLa versión nueva reemplaza la anterior en una operación controlada.
Validar públicoRuta, consola, datos, formulario, automatización y observabilidad.
Rollback si fallaRestaurar versión y estado; conservar evidencia del incidente.
El rollback también se prueba. Un respaldo que nunca se restauró es sólo una esperanza. Antes del go-live se registra qué versión vuelve, quién ejecuta el cambio, qué datos nuevos podrían quedar incompatibles y qué señal obliga a detener la promoción. El tiempo de recuperación forma parte del producto.
Interacción · Incidente
¿Cuál es la respuesta correcta?
No publicar
El build falla antes del despliegue. Producción no se toca y el estado queda bloqueado con el error.
El build falla antes del despliegue. Producción no se toca y el estado queda bloqueado con el error.
Observabilidad por recorrido
Una pantalla verde no prueba el sistema.
| Capa | Prueba | Fallo que detecta |
|---|---|---|
| DNS / TLS | Resolución, certificado y host correctos. | Dominio apuntando mal o certificado inválido. |
| Frontend | Rutas, assets, consola y responsive. | Página parcial, JS roto o caché vieja. |
| Auth | Enlace seguro y sesión válida. | Redirect no permitido o token vencido. |
| Datos | RPC y fila durable bajo RLS. | Falso éxito de formulario. |
| n8n | Job reclamado y conciliado. | Trigger muerto, retry infinito o duplicado. |
| Proveedor | Aceptación y evento posterior. | Transporte aceptado sin entrega. |
| Analytics | Evento tras backend y consentimiento. | Conversión duplicada o PII filtrada. |
La verificación recorre una historia completa: una persona abre la página, consiente, confirma identidad, queda inscrita, genera un trabajo, el proveedor lo acepta y el mensaje llega. Cada salto tiene su propio identificador y reloj. Sin esa cadena no se puede distinguir una caída real de un tablero incompleto.
Go-live de OmniMarket
El checklist que decide si se publica.
Recorrido crítico
Registro, autenticación, estado, baja y error accionable funcionan.
Acceso mínimo
RLS activo, secretos fuera del cliente y superficie administrativa restringida.
Integridad
Restricciones, migración, backup restaurable e idempotencia.
Detección y respuesta
Logs, alertas, dueño, runbook y criterio para rollback.
Eventos honestos
Consent Mode, una sola capa y conversión posterior al backend.
Responsabilidad
Quién aprueba, quién atiende fallos y qué métrica decide continuar.
Capstone 0 → 100
OmniMarket ya es un sistema explicable.
ContextoFuentes, archivos y reglas.
MétodoSkills y objetivos verificables.
CapacidadPlugins, MCP y permisos.
EjecuciónAgentes, Supabase, n8n y VPS.
Criterio de graduación
Otra persona puede entender, ejecutar, verificar y detener el sistema.
La calidad final no es el número de herramientas. Es la claridad con que el sistema conserva contexto, limita efectos, produce evidencia y responde cuando algo falla.
Cierre del curso
Lleva un proceso de tu negocio de 0 a producción.
Empieza por una tarea frecuente, reversible y medible. Documenta el método, conecta sólo lo necesario y conserva aprobación humana donde existe riesgo real.