Topología de despliegue

TED OS corre en Vercel (los front-ends), Fly (la API), Postgres (gestionado, en Fly) y Clerk (auth). Esta página es el mapa de dónde vive cada pieza.

El entorno se nombra solo por su nombre

La configuración de despliegue (conexiones de base de datos, el token de GitHub, claves de Clerk, la capa de modelo) vive en variables de entorno. Esta página nombra esas variables solo por su nombre y nunca incluye valores, tokens ni secretos.

El mapa

   Vercel                              Fly  (app: tedos-api)
   ┌──────────────────────┐           ┌───────────────────────────────┐
   │ admin  app.…         │           │  proceso web                  │
   │ console …            │  HTTPS →   │   Fastify: /projects /p/:id/* │
   │ comprender (cliente) │           │   /engine/* /plan/* /webhooks │
   │ docs   docs.…        │           ├───────────────────────────────┤
   └──────────┬───────────┘           │  proceso worker               │
              │                       │   handler pg-boss + cron      │
          Clerk (auth, compartida     └───────────────┬───────────────┘
          entre subdominios)                          │
                                          ┌───────────▼────────────┐
                                          │ Fly Managed Postgres   │
                                          │  esquema plan (grafo)  │
                                          │  esquema product (SoR) │
                                          └────────────────────────┘

Front-ends — Vercel

El admin, la consola, las apps de cliente como comprender y este sitio de documentación se despliegan en Vercel, cada uno en un subdominio de tuempresa.digital. Comparten la sesión de Clerk vía la cookie raíz — ver Auth.

API — Fly (web + worker)

La API se despliega en la app Fly tedos-api como dos grupos de procesos desde una única imagen:

• web — la API Fastify (las rutas de producto, /engine/*, /plan/*, los webhooks, /healthz).
• worker — el handler pg-boss + cron (los jobs de espejo grafo→GitHub, jobs de refresco).

Un único comando de release corre ambos conjuntos de migraciones antes de que cualquier máquina nueva sirva tráfico, y aborta (fail-closed) si la variable de entorno de conexión de cualquiera de las bases de datos no está definida.

Bases de datos — dos, en un clúster

La regla dura de la plataforma se concreta en el despliegue: dos bases de datos separadas, hoy en el mismo clúster Fly Managed Postgres, aisladas por esquema Postgres:

Esquema	Base de datos	Guarda
plan	grafo del flujo de trabajo / Plan Engine	nuestros planes + tareas (el corpus de trazas de entrenamiento)
product	Sistema de Registro del producto	datos de los clientes, aislados por cliente

Compartir un clúster es un compromiso documentado (aún no hay datos reales de tenant) con una ruta de actualización registrada: mover el grafo de planes a un clúster dedicado antes de volumen real de PII de tenant o cualquier exportación externa de datos de entrenamiento. Ver Plan Engine y SoR del producto.

Mecánica de despliegue

• Los front-ends de Vercel se construyen en remoto desde una fuente limpia; los despliegues ocurren en releases / testing, no en cada push.
• La API de Fly se construye desde la raíz del repo (el build de Docker necesita el workspace pnpm completo como contexto); la división worker y ambos conjuntos de migraciones son parte de la configuración de Fly.

Notas

• Un plan de infraestructura separado y anterior apuntaba a DigitalOcean App Platform + un updater de escritorio Tauri. La topología tal como está construida es la de Vercel + Fly descrita aquí; el plan de DigitalOcean es contexto histórico.
• Los dominios personalizados (p. ej. api.tuempresa.digital) se sitúan delante de la app de Fly vía DNS.