Infrastructure Layer
Pick the shortest infrastructure exit first.
- Host shape: One Mac mini still anchors the whole substrate, with local persistence and a single place to reason about trust, ports, and restart paths.
- Runtime split: Clawdy now serves as a native OpenClaw host process while most specialist agents still run as Docker workloads with the same shared bridge-network assumptions.
- Ingress rule: Tailscale remains the normal team path; Funnel only exposes selected public entry points like Bridge, hooks, Oracle, the Linear Agent Gateway, Samwise, and QMD.
- Boundary: Atlas explains placement, persistence, and shared-service ownership here first, then sends live telemetry and missing-data questions to Observability and uses API Reference only after the service-owning route is clear.
Choose the infrastructure question you arrived with
Start with Platform Stack
Open the street page when the missing answer is host layout, runtime placement, networking, or deployment mechanics in more concrete detail.
Best when you already know the question is about ports, host-versus-container placement, restart mechanics, or the concrete runtime shape.
Stop once you can name the host surface, the workload placement, and the layer that owns the next operational move.
Keep the infrastructure layers separate
Jake's Mac mini remains the physical and virtual anchor for the network, which keeps trust, restart paths, and local persistence legible instead of hiding them behind a distributed platform story.
Atlas documents the simplicity on purpose: one host, one storage surface, and one place where host-native control surfaces and containerized workloads meet.
Clawdy now serves directly from a native OpenClaw host process while Scout, Atticus, Meg, Grafton, and Samwise continue to run as containerized workloads with shared bridge-network assumptions.
The infrastructure story is no longer "everything is a container." The safe mental model is host-level gateway plus specialist containers, with Atlas pointing readers to the live stack detail only when they truly need it.
Tailscale is still the default access path. Funnel only fronts the small public ingress layer for Bridge, hooks, Oracle, the Linear Agent Gateway, Samwise, and QMD.
That boundary keeps Atlas educational: Infrastructure explains which ingress model exists, while Observability and the deeper stack page handle the live questions those surfaces raise.
Bridge, Recall/QMD, RAG Sync, Currybox, Kokoro Proxy, Drop, the QMD Public Proxy, and the observability compatibility layer are host-level shared services, not free-floating route owners.
Atlas should point readers toward the service-owning route when the question becomes specific. API Reference now carries the older request-shape context only after that split is clear, while Observability owns live-signal interpretation.
Know what persists, and which old observability pieces are only context now
The bind-mounted workspace at /home/node/.openclaw/workspace persists projects, charter state, logs, memory, and shared execution surfaces across restarts.
Historical SQLite context stays on the host filesystem for collector-era request shapes, but current telemetry lands in OpenObserve, and Watchtower interprets it against expected state.
The host-level embedding store persists across restarts so Recall/QMD and the QMD Public Proxy do not need a full re-index unless the store is intentionally cleared.
Infrastructure still documents the legacy collector compatibility surface, but Atlas now treats it as background context while current live evidence flows through OpenObserve-first observability routes.
Use the current restart and deploy rules, not the old all-containers assumption
Editing AGENTS.md, ROADMAP/BLOCKERS/SCRATCHPAD surfaces, or shared skills changes the next cycle's behavior without rebuilding an app image.
Use the gateway restart path when the host-level assistant surface needs a bounce. It is distinct from container redeploys and does not imply a full platform restart.
Shared services stay independent: bump the package, merge to main, let CI publish, then restart the affected host service instead of treating every change like a fleet-wide deploy.
Atlas and sibling web apps still build inside their project repos; the infrastructure district should explain that they are consumers of the platform, not the platform itself.
Adding host wiring or new public mappings remains a real owner boundary. Atlas can explain the dependency, but it cannot pretend that a containerized charter owns host-level compose and entrypoint changes.