Documentation Index
Fetch the complete documentation index at: https://docs.kindling.systems/llms.txt
Use this file to discover all available pages before exploring further.
Topology and Hostnames
Kindling can serve multiple public surfaces from the same process, but they should be modeled as different hostnames.Supported production topologies
Kindling officially supports two self-hosted shapes. Other layouts are untested. Primary — all-in-one: API, edge, WAL listener, reconcilers, worker runtime, and PostgreSQL on a single host. Best default for most teams. Secondary — control plane + remote workers: One host runs the full control plane and PostgreSQL; additional hosts are worker-only (local runtime + deployment VMs). All processes share one PostgreSQL cluster. VM backend IPs for the edge are host-local unless you provide operator-managed routing between hosts or enable Kindling-managed WireGuard (see Private networking and production setup). API-only replicas: Extra hosts may run API-onlykindling serve for horizontal API capacity; they do not appear in GET /api/servers unless that process also runs edge or worker. See the HA guide for details.
For ports, storage, DNS, and an explicit unsupported list, see the repo guide High Availability and Supported Topologies (docs/high-availability.md).
Recommended Host Layout
api.kindling.systemsfor REST, Connect, and webhooksapp.kindling.systemsfor the dashboard SPAdocs.kindling.systemsfor documentation
Why Split Hosts
This keeps:- browser API calls pointed at the real API origin
- dashboard assets separate from API semantics
- CORS and cookie behavior easier to reason about
- docs as a separate public surface that does not need to share the dashboard app
Dashboard Build Input
The dashboard build needs the public API origin baked in throughDASHBOARD_API_URL, for example: