A sidecar here is long-running compute in a separate process with an explicit lifecycle: start, health, stop — talking to main over IPC or localhost HTTP. The docs call it baby Docker at crib scale: isolation and swap-ability without requiring a full container registry day one.
Real Docker gives you images, cgroups, overlay FS. Coffee sidecars start with spawn + contract (manifest, protocol). You can wrap real OCI containers later; the mental model is what matters: something that stays alive and owns a concern (inference proxy, workspace API, managed DB) while the main server coordinates routes and auth.
Vault is the first-class sidecar: all vault filesystem I/O in the worker; main is the IPC client. Optional add-ons (workspace, managed DB, deploy helpers) follow the same lazy fork idea: start when needed, speak a contract, stay out of the main loop until called.
Moo = bursty job, hard timeout, go away when done. Sidecar = roommate until you evict it. If it needs to listen or watch for a long time, it is sidecar-shaped; if it is “run this handler and return JSON,” that is Moo-shaped.
The sidecar package includes a container registry list for POC cards (e.g. Ollama vs mock) so UIs can stay data-driven. SIDECAR1 is explicitly a UI mock; SIDECAR2 explores layout/responsive shell patterns — the POC tiles call out what is live versus storyboard.
Remote sidecars (e.g. storage on a VPS) reuse the same contract idea; only transport becomes TLS/VPN. Latency and auth become the hard parts.
A manifest is how long-lived workers are declared in a real deployment: one source of truth instead of every screen guessing spawn arguments. Coffee’s POCs preview that discipline without asking you to edit manifests by hand.