Instancia dedicada (Zentto Edge)

Un cliente Enterprise puede exigir que su ERP corra en su propio servidor (on-prem o su nube), no en la plataforma compartida. Zentto Edge es ese stack: API + shell + caja/mostrador + PostgreSQL + nginx + túnel Cloudflare, levantado con un solo docker compose en cualquier host Linux con Docker.

Validado de punta a punta en el Edge Lab (Pulse 627, 2026-09-13): un contenedor LXC en el hipervisor propio sirviendo datqbox.online con el tenant de Repuestos San José restaurado en local (25.535 artículos), login real contra el broker central y grids con datos de la BD local.

Arquitectura

Internet ──► Cloudflare (DNS + TLS) ──► túnel cloudflared (solo salida)
                                             │
                                       edge-nginx :80
                                       ├─ dominio.com       → shell ERP (edge-frontend:3000)
                                       ├─ /api/ /v1/ /media → API local (edge-api:4000)
                                       └─ caja./mostrador.  → POS (edge-pos:3000)
                                             │
                                       edge-db (PostGIS 16)
                                       ├─ master local (copia del central)
                                       └─ zentto_tenant_<cliente>

Decisiones clave, todas ensayadas en el lab:

Decisión	Cómo queda
Identidad	Híbrida: login contra el broker central auth.zentto.net (mismas credenciales que el SaaS); todo lo demás local.
Red	Cero puertos entrantes: el túnel Cloudflare es outbound-only, como el Data Gateway on-prem. No se toca el firewall del cliente.
Dominio	El mismo mecanismo white-label del SaaS: usp_cfg_tenant_setcustomdomain pero en el master local, y los orígenes en el broker central.
Imágenes	Las mismas de producción (ghcr.io/zentto-erp/*:latest), transferidas por SSH streaming — el edge no necesita credenciales de ghcr.
Datos	Restore de dumps (pg_dump -Fc) del master y de la BD dedicada del tenant.

Dónde vive el automatismo

Todo en zentto-infra/edge/ (PR #181): docker-compose.yml, vhost nginx plantillado, y scripts/ con el bootstrap en el orden probado:

1. pull-images.sh — imágenes prod por SSH streaming (~4,5 GB).
2. setup-db.sh <tenant_db> — rol de app, BDs, restore de dumps, grants.
3. render-env.sh <dominio> — deriva los env del edge desde los de prod (BD local, auth central, URLs del dominio) y renderiza el vhost.
4. tunnel-setup.sh <dominio> — corre en el servidor central (tiene las credenciales CF): crea el túnel, configura ingress y repunta el DNS del dominio; deja el token para el .env del edge.
5. Orígenes del dominio en el broker central (paso 4 del runbook white-label).
6. start.sh <dominio> <companyId> — registra el dominio en el master local y levanta el stack.

El detalle operativo (requisitos, verificación, backups, update de imágenes) está en el edge/README.md del repo.

Qué falta para venderlo (no salir del laboratorio sin esto)

1. Master mínimo: hoy el master local es un dump completo del central, que lleva datos de otros tenants al servidor del cliente. Hace falta un bootstrap de master con solo catálogos + el tenant. Bloqueante para un despliegue real.
2. Login offline: sin internet no hay login (broker central). Falta modo degradado.
3. Canal de actualización y licencia: hoy las imágenes se re-pullean a mano; no hay control de versión ni licenciamiento por instancia.
4. Migraciones: los goose nuevos no llegan solos al edge; el CD central no lo ve.

Contexto de diseño: DatqBoxWeb/docs/design/OFFLINE_POS_RESILIENCE.md (ZENTTO-190) — la topología “servidor en el local del cliente” se aprueba solo si el cliente la financia; este stack es exactamente ese caso, ya ensayado.