Coffee Server is the spine of Coffee Pro on your machine: it is built on Node.js — JavaScript running on the server, the same broad technology family used across the industry. That runtime listens for browser requests and powers the APIs behind Vault, Keyman, Moo, and the demo pages you open from the dashboard. In normal use you do not install packages or type shell commands; the Coffee app starts this engine for you. Architecturally it is still one coordinator process: it wires routes, auth, and lifecycle, while heavy or risky work moves to sidecars and workers you will meet in later modules.
In a naive app, every feature runs in the same event loop: file watchers, AI proxies, and user HTTP all compete for attention. Coffee Server follows a browser-like split: a thin main thread coordinates; I/O-heavy or untrusted code runs elsewhere (child process / worker). That is the same instinct as Web Workers — just on the server.
The docs describe verticals — storage (Vault / S4 lane), compute runners (sidecars), short jobs (Moo / Wire), and Guardian (Keyman). You do not need the whole industry vocabulary; you need to see which box owns the disk and who checks the badge at the HTTP door.
Managed cloud gives you a polished console; you rarely see the processes underneath. Running Coffee on a machine you control means you accept responsibility for updates, backups, and exposure — and you interact through dashboards and settings, not by editing source trees. Under the hood the same architectural ideas still apply: you can reason about what is running even when you are not the one compiling it.
This stack is a controlled slice of “real” architecture: same ideas as S3 + IAM + Lambda + ECS, but sized for a laptop or a home box — fewer knobs, and POC pages you can actually open from the product.
When Coffee Server is up, your browser loads static demos (Vault, Keyman, Moo, sidecar mocks) from the same environment as the API — one coherent install. Files you care about land under a vault root (often a Coffee folder on your desktop or another path you chose in settings). You explore and enable features from SERVER-DEMO and the sidebar POCs, not from a terminal.
If a panel cannot reach the API, it is usually network, address, or permissions — the dashboard’s reachability section exists to surface what URL the browser should use (local vs tunneled) without you debugging fetch by hand.