livediagram

Deploying livediagram

The apps that make up livediagram and how they deploy to Cloudflare. A conceptual map, with the repo as the authoritative guide.

livediagram is not one application but a small set of apps that each deploy as their own Cloudflare Worker, stitched together at a single hostname. This page is a conceptual map of how the pieces fit so the deployment makes sense. For the exact commands and account setup, the repository and its self-hosting guide are the authoritative source.

The apps

The product is split into focused apps, each deployed as a named Cloudflare Worker.

  • marketing serves the public landing site at the root.
  • live is the diagram editor itself, served at clean routes such as /new and /explorer.
  • telemetry is the public, read-only analytics dashboard at /telemetry.
  • api is the Worker that holds the REST and WebSocket layer, backed by the D1 database and the per-diagram Durable Object.
  • router sits in front and forwards each request to the right app by URL path. It holds no business logic, only routing.

There is also a help app (the site you are reading now), which is another static app served under its own path. The router is what makes all of these appear under one domain.

How a request is routed

The router Worker inspects the path and forwards accordingly: /api/* to the api Worker, /telemetry to the dashboard, the editor's known route segments to the live app, and everything else to marketing. Because the router has service bindings to the other apps, those apps must exist before the router can be deployed.

How it deploys

Deployments run through GitHub Actions to Cloudflare Workers. In broad strokes:

  1. Continuous integration runs lint, format, typecheck, test, and build on every push.
  2. A separate, manually triggered deploy workflow builds everything, then deploys the apps.
  3. The marketing, live, telemetry, and api Workers deploy in parallel; the router deploys last because its bindings depend on the others already existing.
  4. Database migrations are applied to D1 as part of the api deploy, before the new Worker code goes live.

Deploying needs a Cloudflare API token and account id, supplied as repository secrets, never committed to source.

This is a conceptual overview, not a step-by-step runbook. For exact commands, required token permissions, and first-deploy ordering, follow the repository's docs/self-hosting.md and the deployment workflow in the source.

Next, see configuration and optional auth for the environment variables that turn optional features on or off.

Was this article helpful?