How It Works
The Panel is a web service you deploy once. Each Core is a daemon on a machine that already has your code. The Panel dials; a Core never dials back.
sequenceDiagram
participant Browser
participant Panel
participant Core
Browser->>Panel: panel-link (session cookie)
Panel->>Core: dial core-link on 8443 (mTLS + bearer)
Note over Core: SQLite, PTYs, projects
Core-->>Panel: events, PTY frames, snapshots
Panel-->>Browser: live UI
What the Core owns
A Core is the only process that writes its own state. It owns the projects, the sessions, the SQLite database, and the PTYs. Path validation is its job: a project's path is a machine path, so only that OS can accept or refuse it. Mutations travel as core-link frames. Missed events replay from a monotonic cursor when the Panel reconnects.
A Core on the Panel's own host is still a Core. There is no local mode and no in-process transport. Install it and pair it like any other.
What the Panel owns
The Panel holds the Core registry, the Operator, and presentation (project grouping, card images, preferences). It stores one lastEventId per Core so reconnect can request the replay tail. Nothing task-shaped lives there — no session logs, no project folders, no harness credentials.
It speaks plain HTTP on port 7420. TLS belongs to your reverse proxy. The core-link is mutual TLS the Core mints itself; you do not terminate or renew that.
Dial direction
Expose one HTTP port for the Panel, reachable by your browser. On each Core, expose port 8443 (default) from the Panel's machine. That Core port needs no route from the public internet. In the reference Compose the two share a network and the Core publishes no port at all.
Every Core is reached the same way. Adding a machine does not require Panel-side per-Core code: pair it, and its work shows up in Fleet.
