Deploy OpenClaw and Hermes Agent in a Sandbox0 Sandbox

OpenClaw and Hermes Agent have moved past the "try it on my laptop" phase.

As of June 8, 2026, OpenClaw has more than 377,000 GitHub stars and Hermes Agent has more than 186,000. Both projects are large enough that the practical question is no longer only "what can the agent do?"

The harder question is:

Where should the agent gateway run once it needs to stay online, keep memory, expose an endpoint, and touch real tools?

Most deployment guides answer that question with one of a few familiar targets:

• run it on your laptop
• run it in Docker
• put it on a VPS
• deploy it to Kubernetes
• use a one-click host such as Railway, Fly.io, Render, or a VPS template

Those paths are useful. They also make the machine or container host the operational boundary for the agent. Filesystem state, public ingress, credentials, network policy, process lifecycle, backups, and cleanup all tend to collapse onto the same long-lived host.

Sandbox0 gives these agents another deployment shape: run the agent framework gateway inside a Sandbox0 sandbox, persist agent state on a SandboxVolume, and put public routes, network policy, credential injection, and lifecycle controls around the agent instead of inside it.

This is the agent-in-sandbox pattern.

Current OpenClaw Deployment Options#

OpenClaw's own install documentation covers a broad matrix: local installers, npm/pnpm/bun/source installs, Docker, Podman, Nix, Ansible, VPS deployments, Docker VM runtime, Kubernetes, Fly.io, Hetzner, GCP, Azure, Railway, Render, Northflank, and more.

That breadth is a market signal. Users are not only experimenting locally. They want OpenClaw to stay reachable from chat channels, dashboards, browsers, and automation flows.

The official Docker documentation makes one important distinction: Docker is optional, and the Docker gateway path is for a containerized gateway or disposable gateway environment. OpenClaw's own sandboxing model is a separate layer. When OpenClaw sandboxing is enabled, the Gateway still stays on the host while tool execution can move into a sandbox backend such as Docker, SSH, or OpenShell.

That distinction matters:

• OpenClaw in Docker puts the gateway process in a container.
• OpenClaw tool sandboxing isolates selected tool execution.
• OpenClaw in Sandbox0 runs the gateway itself inside a Sandbox0 runtime boundary and lets Sandbox0 own the surrounding platform controls.

The last option is different from asking OpenClaw to sandbox its own tools. It changes where the agent gateway, workspace, logs, sessions, service route, and network policy live.

Current Hermes Agent Deployment Options#

Hermes Agent has a similar split.

The official quickstart starts with desktop, CLI, provider setup, and gateway setup. For safety, it recommends running the agent in a Docker container or on a remote server when moving beyond local usage.

The Docker documentation is explicit that Docker appears in two different roles:

1. running Hermes itself inside Docker
2. using Docker as a terminal backend while Hermes runs elsewhere

In Docker gateway mode, Hermes stores its user data in /opt/data: config, API keys, sessions, skills, memories, cron jobs, hooks, logs, and related runtime state. The image is stateless; the mounted data directory is the source of truth.

That makes Hermes a natural fit for a persistent volume model. The agent gateway can be replaceable, but the state directory should be durable, versionable, and protected from accidental multi-writer access.

Why A VPS Is Not The Runtime Boundary#

A VPS gives an agent a durable machine.

That is simple, but it also turns the machine into the trust boundary:

• provider keys and integration tokens often live on the same filesystem the agent can read
• logs, sessions, plugins, browser state, and workspaces accumulate on one host
• public dashboard and gateway exposure must be hardened separately
• snapshots, forks, backup, restore, and cleanup depend on host automation
• network policy is usually configured around the VM, not around each agent session

Docker improves packaging and repeatability, but the hard parts remain. You still have to decide what to bind mount, how to expose the gateway, how to protect the dashboard, how to rotate secrets, whether the agent can reach internal services, and what happens when the container restarts with stale locks or partial state.

Kubernetes improves orchestration, but a raw Deployment and PVC still leave application-level choices to the operator: which state path is durable, which ingress route is public, which token is checked before traffic reaches the agent, whether the agent can call internal networks, and how to pause or replace runtime compute without losing the workspace.

Agent-in-sandbox is a more specific contract:

The sandbox is the agent host. The volume is durable state. The route is the public entrypoint. Network and credential controls sit outside the agent process.

Deploy OpenClaw In Sandbox0#

Sandbox0 ships an agent-in-sandbox guide for OpenClaw.

The built-in openclaw template uses the upstream OpenClaw image:

text
ghcr.io/openclaw/openclaw:latest

It declares this persistent mount point:

text
/home/node/.openclaw

The deployment shape is:

1. create a RWO SandboxVolume
2. claim the built-in openclaw template
3. mount the volume at /home/node/.openclaw
4. start the OpenClaw gateway as a cmd Sandbox Service
5. expose the gateway through a public Sandbox Service route
6. check a Sandbox0 route token before traffic reaches OpenClaw
7. pass a separate OpenClaw gateway token to OpenClaw itself

That token split is intentional.

OPENCLAW_ROUTE_TOKEN protects the Sandbox0 public route. It is checked before a request reaches the sandbox. OPENCLAW_GATEWAY_TOKEN is passed to OpenClaw for its own gateway authentication.

This gives operators two enforcement points:

• route-level policy at the Sandbox0 service layer
• framework-level auth inside OpenClaw

It also gives OpenClaw a durable home directory without turning the VM into the durable source of truth.

Deploy Hermes Agent In Sandbox0#

Sandbox0 also ships an agent-in-sandbox guide for Hermes Agent.

The built-in hermes template uses the upstream Hermes image:

text
nousresearch/hermes-agent:latest

It declares this persistent mount point:

text
/opt/data

That matches the Hermes Docker model, where /opt/data holds the agent's configuration, sessions, memories, skills, logs, and gateway state.

The deployment shape is:

1. create a RWO SandboxVolume
2. claim the built-in hermes template
3. mount the volume at /opt/data
4. configure Hermes API server env vars
5. start the Hermes gateway as a cmd Sandbox Service
6. expose port 8642 through a public route
7. check a Sandbox0 route token before traffic reaches Hermes

Sandbox0 starts Hermes through procd, so the example runs the Hermes binary directly instead of relying on the Docker image entrypoint. The active runtime home is kept under /workspace/.hermes and synced with the mounted /opt/data volume when the process exits.

That keeps the agent process restartable while preserving the data Hermes expects to survive.

What Sandbox0 Owns Around The Agent#

The agent framework still owns its application behavior.

OpenClaw owns OpenClaw sessions, channels, tools, and gateway semantics. Hermes owns Hermes profiles, sessions, skills, memory, and API behavior.

Sandbox0 owns the runtime boundary around those processes:

That boundary is useful because autonomous agents mix several risk domains:

• untrusted messages and webpages
• shell commands
• file operations
• model provider credentials
• GitHub, Slack, Discord, Telegram, and email tokens
• long-lived memory and sessions
• public service endpoints

Putting all of that on one machine and calling it "self-hosted" is operationally simple. It is not the same thing as having a clean runtime boundary.

Persistent State Belongs On Volumes#

For both OpenClaw and Hermes, the important state should live on a SandboxVolume.

Sandbox0 Volumes are independent of the sandbox lifecycle. A sandbox can be replaced while the volume remains. Volumes can be snapshotted and restored. Mounted RWO volumes have one active writable owner, which fits agent state directories that should not be written by multiple gateway processes at the same time.

That maps cleanly to these paths:

The writable root filesystem of a sandbox can be checkpointed across pause and resume, but long-term agent state should still be placed on a volume. The volume is the durable product state. The sandbox runtime is replaceable compute.

Public Routes Should Be Policy Boundaries#

OpenClaw and Hermes both expose gateway or API surfaces.

In a VPS deployment, that usually means binding a port, placing a reverse proxy in front, and being careful not to expose the wrong interface.

In Sandbox0, that public entrypoint is a Sandbox Service route. The route can apply policy before proxying to the sandbox:

• method filtering
• bearer or header auth
• CORS
• route timeouts
• rate limits
• path rewrites
• paused sandbox resume

For agent gateways, the important part is that route auth happens before the request reaches the agent framework.

The agent can still enforce its own auth. Sandbox0 gives the operator a platform-level gate first.

See Sandbox Services for the route model.

Network And Credential Boundaries Should Live Outside The Agent#

Do not mount broad cloud credentials or a developer home directory into an agent sandbox.

For higher-control deployments, prefer one of these patterns:

• route model traffic through LLMProxy or another external model proxy
• use Sandbox0 credential sources and egress auth for destination-scoped outbound auth
• give the framework only a narrow application token when it requires one
• keep route auth at the Sandbox0 service layer
• define sandbox network policy by destination, port, protocol, and tool protocol where possible

This does not make prompt injection disappear. It reduces the blast radius when an agent processes hostile input, runs a bad tool, installs an unsafe package, or tries to reach a destination it should not touch.

The runtime boundary should not depend on the model remembering a rule.

Pause And Resume Are Useful, But Not For Every Agent Gateway#

Sandbox0 can pause a sandbox to release runtime compute while keeping the sandbox identity, configuration, mounted volumes, and rootfs checkpoint.

If the sandbox has auto_resume: true and the public route has resume: true, a later request can resume the sandbox and restart the cmd service.

That works well for request-driven gateway traffic.

It is not a substitute for preserving live sockets. Pause does not preserve running processes, memory, sockets, or in-flight requests.

For OpenClaw or Hermes workflows that depend on outbound long polling, WebSockets, cron, or always-on channel connections, choose one of these designs:

• keep the sandbox running
• put webhook receivers or schedulers in an always-on control plane that calls the Sandbox0 service URL
• use pause/resume only for request-driven routes

That distinction should be made up front. A gateway that needs to listen continuously is not the same as a gateway that only needs to wake when a public request arrives.

When To Use This Pattern#

Use agent-in-sandbox for OpenClaw or Hermes when you want:

• the gateway and workspace isolated from the host
• persistent memory, sessions, skills, and logs on a mounted volume
• a public HTTP route with platform-level auth
• network policy outside the agent process
• destination-scoped credential injection
• replaceable runtime compute
• self-hosted or private-cluster deployment through Sandbox0

Use a direct local install when you are experimenting on your own machine.

Use a simple Docker or VPS path when you accept host-level operations and can harden it yourself.

Use Sandbox0 when the agent runtime boundary needs to be a platform primitive, not a collection of shell scripts and reverse proxy settings.

Start Here#

The full SDK examples are in the Sandbox0 docs:

• Agent in Sandbox
• OpenClaw on Sandbox0
• Hermes Agent on Sandbox0
• Sandbox Services
• Sandbox Volumes

The short version:

Create a volume. Claim the openclaw or hermes template. Mount the framework state directory. Expose the gateway as a Sandbox Service. Keep public route auth, network policy, and credential boundaries outside the agent process.