Deploy topology

TED OS runs across Vercel (the front-ends), Fly (the API), Postgres (managed, on Fly), and Clerk (auth). This page is the map of where each piece lives.

Environment is referenced by name only

Deploy configuration (database connections, the GitHub token, Clerk keys, the model layer) lives in environment variables. This page names those variables only and never includes any values, tokens, or secrets.

The map

   Vercel                              Fly  (app: tedos-api)
   ┌──────────────────────┐           ┌───────────────────────────────┐
   │ admin  app.…         │           │  web  process                 │
   │ console …            │  HTTPS →   │   Fastify: /projects /p/:id/* │
   │ comprender (client)  │           │   /engine/* /plan/* /webhooks │
   │ docs   docs.…        │           ├───────────────────────────────┤
   └──────────┬───────────┘           │  worker  process              │
              │                       │   pg-boss handler + cron      │
          Clerk (auth, shared         └───────────────┬───────────────┘
          across subdomains)                          │
                                          ┌───────────▼────────────┐
                                          │ Fly Managed Postgres   │
                                          │  plan schema  (graph)  │
                                          │  product schema (SoR)  │
                                          └────────────────────────┘

Front-ends — Vercel

The admin, console, client apps like comprender, and this docs site deploy to Vercel, each on a subdomain of tuempresa.digital. They share the Clerk session via the root cookie — see Auth.

API — Fly (web + worker)

The API deploys to the Fly app tedos-api as two process groups from a single image:

• web — the Fastify API (the product routes, /engine/*, /plan/*, the webhooks, /healthz).
• worker — the pg-boss handler + cron (the graph→GitHub mirror jobs, refresh jobs).

A single release command runs both migration sets before any new machine serves traffic, and aborts (fail-closed) if either database's connection env var is unset.

Databases — two, on one cluster

The platform's hard rule plays out at deploy time: two separate databases, today on the same Fly Managed Postgres cluster, isolated by Postgres schema:

Schema	Database	Holds
plan	dev-workflow / Plan Engine graph	our plans + tasks (the training-trace corpus)
product	product System of Record	clients' data, isolated per client

Sharing one cluster is a documented compromise (no real tenant data yet) with a tracked upgrade path: move the plan graph to a dedicated cluster before real tenant-PII volume or any external training-data export. See Plan Engine and Product SoR.

Deploy mechanics

• Vercel front-ends build remotely from a clean source; deploys happen on releases / testing rather than every push.
• The Fly API builds from the repo root (the Docker build needs the full pnpm workspace as context); the worker split and both migration sets are part of the Fly config.

Notes

• A separate, earlier infrastructure plan targeted DigitalOcean App Platform + a Tauri desktop updater. The as-built topology is the Vercel + Fly one described here; the DigitalOcean plan is historical context.
• Custom domains (e.g. api.tuempresa.digital) sit in front of the Fly app via DNS.