Skip to content
🧭
Platform reference

Infrastructure & Deployment

How the Saffron Network is hosted, deployed, and networked together.
Validated Β· Oct 6, 2026Revalidated on October 6: the agent roster's Clawdy row now teaches the verified GPT-6 model β€” self-reported from Clawdy's own gateway config over Bridge. The 2026-09-30 pass re-probed every agent gateway as part of the September 30 gateway topology convergence and the port map onto the live shared-instance split (lc-builders 18811: Samwise + Scout; lc-makers 18814: Dexter, Buzz, and Meg; lc-stewards 18805: Atticus + Grafton; Clawdy via the 18789 ssh forward, its gateway riding minip3), retiring the container-era 18796/18802/18809 spellings and Meg's preview mirrors. The current service inventory and Bridge v1 command surface hold β€” the Saffron Orchestrator work queue (18830, live since 2026-08) remains in the host-support layer, and the Tailscale Funnel entry reflects the current five-route public ingress shape. The agent roster and runtime split are unchanged: Dexter operates via direct surfaces (Slack, Notion, CurryChat), and Buzz via Bridge and CurryChat β€” the pair's shared direct surface β€” rather than dedicated gateway ports; this pass converged their surface teaching onto the registry. The compose edit-point story still teaches: live compose edits run through saffron-root services/docker/ (live-verified 2026-07-10), with the older Atticus-clone lane retired. The October 2 Drop Port Convergence pass retired the package-default 18821 teaching: main-mini's Drop file-pass service runs on 18930 (18821 is Hank's derived Chrome CDP port), while minip3 keeps the 18821 default.
Take the shortest infrastructure jump

Start with the Scout-hosted URLs, the host-support service split, or the per-agent gateway map before you open the deeper platform guide.

Top-level route contracts

Pick the lane, then the page

Atlas stays easier to scan when the route map reads like navigation first. Start with the lane that matches your question, then expand the full page-job model only when you need the deeper contract details.

Current lane: Systems
InfrastructureHere

Platform-surface page for where the network runs and which services or access layers support it.

How the network is builtCurrent pageHigh-change

Change pace: Check recent updates first. These pages move when the network or live support surfaces change.

Best next move
Then inspect the right operational surface

If the system question turns operational, switch from platform shape to the live-status companion.

Open Watchtower Guide
Start here

Entry

Use these pages when you are still orienting and need the safest first click before you pick an owner or system.

3 pages
Home

Shortest whole-site overview before you choose a deeper page.

Steady
Getting Started

Guided first-five-minutes path for readers who want a tour instead of a reference page.

Steady
FAQ

Question-first shortcut when the reader starts with confusion instead of a route plan.

Steady
Who owns the work

Ownership

Use these pages when your real question is who should handle the work, how it moves, or which charter owns the surface.

4 pages
Projects & Charters

Charter and surface ownership map for the network.

Steady
Capabilities

Worker-selection page for choosing the right agent and understanding execution boundaries.

Steady
Coordination

Decision-and-handoff layer for how work gets routed between people, agents, and systems.

Steady
Workflows

Execution-story page for how real work usually unfolds from intake to visible closeout.

Steady
How the network is built

Systems

Use these pages when you need the map, structure, services, and interfaces behind the network instead of the people or routing rules.

5 pages
Network Topology

Whole-network reference map of agents, systems, and relationships.

High-change
Architecture

Rationale layer for why the network is shaped this way and what tradeoffs drove it.

Stable reference
Bridge

Communication-system page for how agents ask, hand off, and consult one another.

Steady
InfrastructureHere

Platform-surface page for where the network runs and which services or access layers support it.

High-change
API Reference

Interface reference for endpoints, payloads, and package-level service details.

Steady
What to do when it hurts

Operations

Use these pages when something feels broken, you need a concrete next check, or you need the live-status companion surface.

2 pages
Troubleshooting

Symptom-first page for named failures, first checks, and practical fixes.

High-change
Watchtower Guide

Operational companion page for when the question is about live health and current status rather than static explanation.

High-change
Infrastructure as a platform map

What brought you to this page?

This page is dense because it spans access paths, runtime placement, service boundaries, and deployment mechanics. Pick the question closest to yours. The summary will show you where to start and where you can stop reading without missing what you need.

Select a question above

The summary will update with a reading plan and a direct jump link.

Validated Β· Oct 6, 2026
What changed in this audit

Validated on October 6: the gateway map teaches the shared-instance topology

Revalidated on October 6: the agent roster's Clawdy row now teaches the verified GPT-6 model β€” self-reported from Clawdy's own gateway config over Bridge. The 2026-09-30 pass re-probed every agent gateway as part of the September 30 gateway topology convergence and converged the port map onto the live shared-instance split (lc-builders 18811: Samwise + Scout; lc-makers 18814: Dexter, Buzz, and Meg; lc-stewards 18805: Atticus + Grafton; Clawdy via the 18789 ssh forward, its gateway riding minip3), retiring the container-era 18796/18802/18809 spellings and Meg's preview mirrors. The current service inventory and Bridge v1 command surface hold β€” the Saffron Orchestrator work queue (18830, live since 2026-08) remains in the host-support layer, and the Tailscale Funnel entry reflects the current five-route public ingress shape. The agent roster and runtime split are unchanged: Dexter operates via direct surfaces (Slack, Notion, CurryChat), and Buzz via Bridge and CurryChat β€” the pair's shared direct surface β€” rather than dedicated gateway ports; this pass converged their surface teaching onto the registry. The compose edit-point story still teaches: live compose edits run through saffron-root services/docker/ (live-verified 2026-07-10), with the older Atticus-clone lane retired. The October 2 Drop Port Convergence pass retired the package-default 18821 teaching: main-mini's Drop file-pass service runs on 18930 (18821 is Hank's derived Chrome CDP port, 18810 + 11), while minip3 keeps the 18821 default. Samwise's gateway-delivery capture predates the July 24 registry retirement β€” this capture taught the then-current Lantern-first intake contract, which the July 24 registry retirement has since superseded with parent-identity skills.

Newly documented service footprint
  • β€’ Tailscale Funnel: / β†’ ClawConnect, /linear-agent, /qmd, /orchestrator, /samwise-hooks
  • β€’ Runtime split: native shared OpenClaw instances β€” Clawdy forwarded on 18789 (its gateway runs on minip3), lc-builders 18811 (Samwise, Scout), lc-makers 18814 (Dexter, Buzz, Meg), lc-stewards 18805 (Atticus, Grafton), Hank 18810; Dexter and Buzz keep their direct charter surfaces
  • β€’ Scout: 18811 (lc-builders), shared with Samwise β€” 18796 retired
  • β€’ Meg: 18814 (lc-makers), shared with Dexter and Buzz β€” 18802 and the preview mirrors retired
  • β€’ Atticus: 18805 (lc-stewards), shared with Grafton β€” 18806–18807 retired
  • β€’ Grafton: 18805 (lc-stewards), shared with Atticus β€” 18809 archived 2026-09-29
  • β€’ Samwise: 18811 (lc-builders), shared with Scout
  • β€’ Linear Agent Gateway: 18820
  • β€’ Drop file pass service: 18930 (main-mini; minip3 keeps the 18821 default)
  • β€’ Saffron Orchestrator work queue: 18830
  • β€’ Observability Collector: 18801
  • β€’ Vision stack: 9200–9202, Kokoro on 8787
  • β€’ Saffron Notify / Deploy Hook: 18892–18893
  • β€’ QMD / vision / oracle / edge helpers: 18790, 18792, 18793, 18795, 18799
  • β€’ Live compose edits: saffron-root services/docker/ β€” edit and recreate there (live-verified 2026-07-10; the retired Atticus-clone lane is history)
Reader takeaway
  • β€’ Scout still fronts the canonical Atlas and Watchtower app URLs for readers
  • β€’ Clawdy still matters as a front-door role β€” its gateway runs on minip3 and answers on 18789 through the ssh forward
  • β€’ Currybot is documented as part of the host-level OpenClaw assistant stack, not as a dedicated local Docker container
  • β€’ Meg's preview mirrors (18803, 5181) retired with her container stack β€” the Scout URLs are the surfaces
  • β€’ Samwise's delivery surface read as Lantern-first on Linear at this July 10 capture; the registry's July 24 single-owner refactor retired the Lantern and Spade charters, so intake and execution now run as parent skills
  • β€’ When infra docs mention compose edits, start from saffron-root services/docker/ β€” an old compose copy in an agent clone is historical drift, not a second source of truth
  • β€’ Dexter and Buzz are Labs agents on registry-direct surfaces β€” Dexter: Slack, Notion, CurryChat; Buzz: Bridge, CurryChat β€” with no dedicated gateway ports
  • β€’ Readers should still start with Scout's Atlas and Watchtower URLs Funnel, Notify, Drop, and the Linear Agent Gateway as the host-support layer
  • β€’ lc-makers (18814) carries Dexter, Buzz, and Meg; Samwise's intake and execution run as parent-identity skills on Linear after the July 24 retirement of the Lantern and Spade charters
  • β€’ Use Atlas for explanation, Watchtower for live state
How to read this page

Start with the platform view, then zoom in

This is a district-level page. Use it when you want to understand where the network runs, how services are grouped, and how access works across hosts, containers, and the tailnet.
Use this page when…
  • β€’ you need the deployment shape, not the design philosophy
  • β€’ you want to know which systems live together and how they connect
  • β€’ you are tracing access boundaries, hosting, or service placement
Choose a different page when…
  • β€’ you need the high-level why behind the network’s design
  • β€’ you care about one workflow, one agent, or one protocol in detail
  • β€’ you are answering β€œwhat does this enable?” rather than β€œwhere does it run?”
Read order
  • β€’ hosting + network boundaries first
  • β€’ then shared services + agent gateways
  • β€’ then leave for the route that answers your next question
Sky follow-up β†’ Architecture

Use this when you want the why, tradeoffs, and design principles behind the infrastructure choices.

Open Architecture
Street follow-up β†’ Bridge

Use this when you want the concrete messaging path between agents rather than the platform shape.

Open Bridge
Map follow-up β†’ Network overview

Use this when you want the whole system map before diving back into one infrastructure slice.

Open Network
Open this URL first

Use Scout's canonical URLs by default

If you just want to reach Atlas or Watchtower, start with the Scout-fronted canonical URLs on the tailnet. Meg’s container-era preview mirrors retired with her stack (2026-09-30 revalidation), so the Scout URLs are the only app surfaces.
Canonical app surfaces
Atlas docs

Primary Scout-hosted docs surface. Use this when you want the canonical Atlas experience.

Canonical18797
http://main-mini:18797/
Watchtower

Primary Scout-hosted observability surface. Use this for live state, not Atlas.

Canonical5175
http://main-mini:5175/
Retired preview mirrors
Meg's Atlas and Watchtower mirrors (retired)

Meg's container-era preview range (Atlas on 18803, Watchtower on 5181) retired with that stack on the 2026-09-30 revalidation. Neither port answers anymore β€” use the Scout canonical URLs above.

Retired18803 Β· 5181
use the canonical Atlas and Watchtower rows above
Service-specific surfaces
QMD Public Proxy

Use only when you want the QMD helper surface itself, not Atlas or Watchtower.

Helper surface18790
http://main-mini:18790/
ClawConnect MCP

Dedicated machine-facing connection point instead of a reader-start URL.

MCP7331
http://main-mini:7331/
CurryChat app

Separate team chat surfaces, not alternate names for Atlas or Watchtower.

Chat app5177–5178
http://main-mini:5177/orhttp://main-mini:5178/
Hosting environment

Physical host, Docker split, and tailnet access

Use this section when you need the runtime placement story: which pieces are native, which are containerized, and how the tailnet and funnel expose them.

Primary Tailnet Host

  • β€’Runs the native OpenClaw gateway instances (lc-builders, lc-makers, lc-stewards) and the 18789 ssh forward to Clawdy’s gateway on minip3
  • β€’Agents run as host processes under per-instance homes rather than per-agent containers
  • β€’Hosts both the working environment and the team-facing deployments
  • β€’Connected to the Tailscale network for secure access

Gateway runtime split (2026-09-30 revalidation)

  • β€’Agents ride native shared OpenClaw instances: lc-builders 18811 (Samwise, Scout), lc-makers 18814 (Dexter, Buzz, Meg), lc-stewards 18805 (Atticus, Grafton)
  • β€’Clawdy’s gateway runs on minip3 and answers on 18789 through a launchd-managed ssh forward; Hank rides 18810
  • β€’The container-era per-agent gateways (18796, 18802, 18809) are retired β€” the standalone Grafton config was archived 2026-09-29
  • β€’Shared Currykit services answer on their host ports (Currybox 18800, QMD 8790, QMD Public Proxy 18790)

Tailscale Mesh

  • β€’Secure team access still defaults to the LC tailnet
  • β€’Tailscale Funnel now adds a narrow public ingress layer for selected routes
  • β€’HTTPS termination and certificate management still ride through Tailscale
  • β€’Web apps (Atlas, Watchtower) are usually accessed via machine hostname on the tailnet

Tailnet-accessible apps

πŸ—ΊοΈ
Atlas
Network documentation and visualization β€” accessible to the LC team via Tailscale
πŸ“Š
Watchtower
Observability dashboard β€” agent activity, bridge conversations, health monitoring

Both apps are still taught as tailnet-first surfaces. Funnel exists for selected public routes, but Atlas and Watchtower remain the canonical internal URLs readers should memorize.

Host-level support services

Not every important surface is an agent port

The network now includes a clearer host-side support layer alongside the agent gateways. These services explain how Linear handoffs, file passing, notifications, observability, and public ingress actually work.
Tailscale Funnel
/ β†’ ClawConnect, /linear-agent, /qmd, /orchestrator, /samwise-hooks

A public routing layer created on Apr 18, reshaped to its current five-route shape at the Aug 7 main-mini upgrade: the root points at ClawConnect, with named paths for the Linear Agent Gateway, QMD remote memory, the Saffron Orchestrator work queue, and Samwise’s token-injecting GitHub hook proxy. Post-restart checks verify all five routes from off-host.

Linear Agent Gateway
18820

Bridges Linear agent protocol traffic into Saffron OpenClaw agents for @mentions, assignment-driven handoffs, tool-driven activity loops, live Codex item streams, button-choice flows, and open-ended elicitation prompts. OAuth auto-refresh keeps longer-running sessions alive, and the newer complete/error session states make the activity panel read more like a real live handoff surface than a one-shot relay. For delivery work, Samwise is the single owner: the gateway surfaces assignment-driven handoffs and intake directly to Samwise, whose parent-identity skills carry planning through verified closeout (the retired Lantern and Spade charters no longer run β€” the Lantern Cycle cron is disabled).

Drop
18930

Content-addressed file-pass service for agent-to-agent handoffs, live-verified on 18930. Main-mini moved Drop off the package-default 18821 on 2026-09-30 via its launchd plist β€” 18821 is Hank’s derived Chrome CDP port (18810 + 11), which his managed Chrome can take on loopback whenever it runs β€” so 18930 sits outside every gateway’s CDP range, while minip3’s Drop keeps the 18821 default. The service still gives the host support layer a dedicated place for moving artifacts between sessions cleanly instead of overloading chat or pretending every transfer is just another document URL.

Saffron Orchestrator
18830

The work queue behind the network’s queue lanes (live since 2026-08, exposed publicly at /orchestrator). Charter cycles pull their lane for deliberately routed work β€” Arbor requests can land here as items β€” but scheduled crons stay the floor: pulls are fail-soft, an unreachable queue reads as an empty lane, and a cycle caps lane work at two or three items before returning to its charter work.

Saffron Notify + Deploy Hook
18892-18893

Own notification delivery and deploy-trigger plumbing outside the app surfaces, so status loops and publish signals do not rely on a browser-facing route.

Legacy SQLite collector
18801 (deprecated)

Deprecated host-level event API on port 18801. Atlas keeps it only for legacy collector-shaped request context; current telemetry lands in OpenObserve, and Watchtower adds expected-state interpretation on top.

Vision stack (MLX + Whisper)
9200-9202

The local vision sidecar, proxy, and Whisper server now form a small support cluster for image and video analysis instead of a single sidecar port.

Public edge helpers
18790, 18793, 18795, 18799

Scoped helper surfaces now include the QMD Public Proxy, Vision Proxy, Currybot Oracle Proxy, RAG Images Server, and Public Web Edge Proxy. Name them when the port map matters, but do not treat them as reader-start URLs.

Currykit services

Shared infrastructure powering the agent network

Use this catalog when the question is about the reusable capability layer underneath multiple agents rather than a single gateway or app route.

@lambda-curry/currykit-recall

Semantic search and knowledge retrieval service. Indexes LC team notes, docs, and knowledge so agents can search by meaning, not just keywords.

POST /embed β€” Generate embeddings
POST /search β€” Semantic search
GET /collections β€” List indexed collections

@lambda-curry/currykit-observability

Legacy collector compatibility surface plus supporting telemetry jobs. Atlas still documents the historical request shape here, but current live evidence now flows through OpenObserve and Watchtower's expected-state model.

Historical GET /events examples
Historical GET /services examples
Historical POST /events examples
Current live path: OpenObserve telemetry + Watchtower interpretation

@lambda-curry/currykit-bridge

Agent-to-agent messaging tool. Lets agents send questions and tasks to each other across different OpenClaw instances.

CLI: bridge call <target> <message> --json
CLI: bridge watch <turnId> --resume --json
CLI: bridge result <turnId> --json
CLI: bridge interject <sessionKey> <message> --json
CLI: bridge cancel <turnId> --reason <reason> --json
CLI: bridge list --json

ClawConnect MCP

:7331

A dedicated MCP surface now documented in the network. It gives Clawdy a separate machine-facing connection point instead of overloading the main gateway list.

MCP service endpoint on port 7331
Used for Clawdy-facing machine integrations

CurryChat app

:5177–5178

Team chat application surface associated with Currybot. Atlas documents it as a separately exposed app layer, without treating Currybot itself as a guaranteed local dependency on every host.

Web app preview surfaces on 5177 and 5178
Pairs with Currybot's broader plugin and hosted footprint when that stack is present

@lambda-curry/currykit-currybox

Cloud sandbox proxy. Routes commands to isolated cloud VMs when agents need a clean, ephemeral execution environment.

POST /run β€” Execute command in sandbox
GET /status β€” Sandbox status

@lambda-curry/currykit-kokoro-proxy

Local TTS service. High-quality speech synthesis for agent responses.

POST /tts β€” Generate speech from text
GET /voices β€” List available voices

@lambda-curry/currykit-rag-sync

Knowledge sync pipelines. Pulls content from Notion, Jira, and Linear and feeds it into the Recall search service so agents always have current context.

Runs as cron jobs
Syncs every 15 minutes

@lambda-curry/currykit-delegate

Delegation tracker. Records when and how coding tasks are handed off to agents like Codex β€” start, completion, failures, and task details.

Event: delegation.started
Event: delegation.completed
Event: delegation.failed

Cost Tracker (currykit-observability)

Monitors API usage costs for agents. Tracks daily and monthly spend, generates alerts on budget thresholds.

Event: tracking.completed
Runs every 6 hours

Monitor Service (currykit-observability)

Scheduled health check and monitoring service. Verifies system status and agent availability.

Event: monitoring.completed
Runs every 2 hours

Codex Telemetry (currykit-observability)

Tracks Codex CLI usage and telemetry. Emits structured events so current observability signals land in OpenObserve and surface through Watchtower.

Structured event logging into the observability pipeline
Agent gateways

Per-agent port ownership without another card wall

Use these rows when you need the gateway owner, role, model, and port range quickly. They are lookup handles, not a list of reader-start URLs.
Clawdy

Jake's primary assistant

Port 18789GPT-6

Gateway runs on minip3; main-mini reaches it through the launchd ssh forward on 18789 β€” no Clawdy process on this host.

Currybot

LC team assistant in the OpenClaw-era assistant stack

Host stackGLM-5.2

Documented as part of the broader host assistant stack rather than a dedicated local Docker container.

Scout

Autonomous explorer

Port 18811GLM-5.3

Rides the lc-builders instance with Samwise (the container-era 18796 gateway is retired). Owns the canonical Atlas and Watchtower reader surfaces that most people should memorize first.

Atticus

Decision-making & governance

Port 18805GLM-5.2

Rides the lc-stewards instance with Grafton (18806–18807 are retired with the container-era split). Operationally historical: Atticus's clone hosted the fleet's live compose edit point until the 2026-06-28 launch-dir migration (live-verified 2026-07-10).

Meg

Design engineer & visual authority

Port 18814GLM-5.2

Rides the lc-makers instance with Dexter and Buzz. Her container-era gateway (18802) and preview mirrors (18803 β†’ Atlas, 5181 β†’ Watchtower) retired with that stack (2026-09-30 revalidation).

Grafton

Lifecycle steward & initiative gardener

Port 18805GLM-5.2

Rides the lc-stewards instance with Atticus since the standalone 18809 gateway was archived (2026-09-29). Useful when tracing stewardship loops rather than app routing.

Samwise

Delivery-loop operator

Port 18811GLM-5.2

The current live delivery lane behind the Linear Agent Gateway: intake, threading, and execution run as Samwise parent-identity skills since the July 24 charter retirement, with the gateway fronting button-choice, elicitation, and scoped delivery flows.

Dexter

Labs leader

Port Direct surfacesGLM-5.2

Labs experiment design and honest assessment for the founding team. Reaches via Slack, Notion, and CurryChat rather than a dedicated gateway port β€” triggered manually or by cron.

Buzz

Distribution & market-signal agent

Port Direct surfacesGLM-5.2

Dexter's distribution counterpart. Finds audiences, designs approved distribution experiments, and manages Reddit Ads with trusted read/write. Reaches via Bridge and CurryChat rather than a dedicated gateway port.

Inter-agent communication

Agents communicate via:

  • Bridge CLI: direct queries and responses between agents
  • Gateway HTTP APIs: programmatic access via the Docker bridge network (internal only)
  • Sessions: isolated or shared conversation context
  • Observability Events: async telemetry and logging
Docker & networking

Container architecture and network topology

This is the closer-grain placement layer: what shares the bridge network, what reaches the host helpers, and where the live compose edits actually happen.

Network topology

Container network
  • Agent instances and shared services run as host processes; the container-era bridge-network split is retired (2026-09-30 revalidation)
  • Surfaces reach host-level helper services through the internal host alias
  • Public ingress is selective through Tailscale Funnel, not blanket port exposure
Service exposure
Each service listens on a dedicated port within the Docker bridge network. Key exposure patterns:
  • Agent gateways β€” reachable via the internal host alias
  • Currykit services β€” internal-only; agents call them through the host's internal service alias
  • Scout still serves Atlas on 18797 and Watchtower on 5175 for tailnet access
  • Meg's container-era preview mirrors (18803 Atlas, 5181 Watchtower) retired with that stack
Volume mounts
  • /home/node/.openclaw/workspace β€” Agent workspace (projects, data, logs)
  • /home/node/.openclaw/config β€” Gateway configuration
  • /app/skills β€” Shared skills library (read-only)
Build infrastructure (saffron-centralized)

All agent Dockerfiles and compose files are centralized in saffron/services/docker/<agent>/ β€” a single place to manage build definitions rather than scattering them across agent workspaces (decided Mar 2026). Since the 2026-06-28 launch-dir migration, the live edit point is the saffron root itself: edit and recreate from services/docker/ (live-verified 2026-06-28, re-verified 2026-07-10). Earlier in 2026 the live edit point routed through Atticus's Saffron clone; that lane is retired.

saffron/services/docker/
_shared/ ← legacy snippet reference (deprecated)
atticus/ currybot/ grafton/ meg/ samwise/ scout/

All images build FROM openclaw:local. As of Mar 2026, the full tool suite (bun, Codex, Playwright, gh CLI, etc.) is baked into the base image β€” agent Dockerfiles stay thin and add only agent-specific identity or config. When tracing where an operator changes container wiring, start from the saffron root's services/docker/ tree β€” a compose copy inside an agent clone is historical drift, not the live edit point.

Security & access control

Authentication, authorization, and trust boundaries

Use this section when the question is about who can reach what, where secrets live, or what the sandbox actually limits.

Authentication

  • β€’Tailscale mesh access: devices on the LC tailnet can reach the canonical internal surfaces
  • β€’Currykit services: bearer-token auth with secrets injected at startup
  • β€’Inter-agent: no extra auth inside the trusted Docker bridge network
  • β€’External APIs: service-specific credentials (GitHub, OpenAI, etc.)

Secret Management

  • β€’Docker env files (.env.local, never committed)
  • β€’OpenClaw gateway config (gateway.toml)
  • β€’No secrets in code or version control
  • β€’Secrets injected at container startup

Network Isolation

  • β€’Most host surfaces stay on the private tailnet
  • β€’Public ingress is limited to the Funnel-routed paths and helpers Atlas documents explicitly
  • β€’Docker containers can't see host filesystem (except mounts)
  • β€’Agents sandboxed by OpenClaw exec policies

Agent Boundaries

  • β€’Compute: Limited to Docker container resources
  • β€’Network: Docker bridge, host helper surfaces, and selective Tailscale/Funnel ingress
  • β€’Storage: Workspace volume + tmp
  • β€’Secrets: Read-only access to assigned env vars
Deployment & updates

How changes move into running surfaces

Use this section when you need the mechanics of agent-code updates, Currykit service refreshes, or app deploys.

Deployment process

Agent code updates
  • Project context (SOUL.md, AGENTS.md, etc.) updated via git
  • OpenClaw automatically picks up changes on restart
  • Use gateway restart tool to apply
Currykit service updates
  • Code changes in lambda-curry/currykit monorepo
  • Build and restart affected services
  • No agent downtime required (services are independent)
Web app deployments
  • Atlas: React Router 7, built and served via Bun
  • Watchtower: React Router 7, built and served via Bun
  • Both are taught as tailnet-first app surfaces, with Meg preview mirrors available when needed
  • Zero-downtime updates (build, then restart server)

Go deeper from infrastructure

Architecture Decisions

Step up a level for the why, tradeoffs, and operating principles behind the platform shape.

Open Architecture Decisions
Bridge Communication

Trace the concrete transport layer that connects agents across the infrastructure.

Open Bridge Communication
Network Overview

Return to the full map when you want to re-anchor this infrastructure slice in the wider system.

Open Network Overview