# Hosting Hermes

Run Hermes inside a Sandbox0 sandbox when you want sessions, memory, skills,
and gateway state behind Sandbox0 lifecycle and network controls. The builtin
`hermes` template keeps its writable state on the sandbox rootfs.

## Create The Sandbox

Claim the builtin template:

```bash
SANDBOX_ID="$(
    s0 -o json sandbox create --template hermes \
        | jq -r '.ID // .id'
)"

s0 sandbox get "$SANDBOX_ID"
```

Use the Sandbox Services API or an SDK claim configuration to expose the Hermes
API as a `cmd` service. Enable `auto_resume` on the sandbox and `resume: true`
on its route when incoming traffic should wake a paused runtime.

## Persistence

Hermes workspace and configuration files live on the writable rootfs. A pause
checkpoints them to encrypted object storage and resume restores them before
Hermes is started again. Deleting the sandbox deletes that rootfs identity.

Create a named [rootfs snapshot](/docs/sandbox/snapshot-restore) before deletion
when you need to preserve or fan out an initialized Hermes workspace. A new
sandbox can be claimed with the snapshot ID, or the current sandbox can be
restored after it is paused.

The default filesystem-only pause does not retain running Hermes processes or
memory; the service starts again after resume. Explicit experimental
[memory pause/resume](/docs/sandbox/pause-resume#explicit-memory-pause-and-resume)
can retain supported process state. External clients must reconnect after
either mode.

## Next Steps

<CardGroup>
  <Card title="Sandbox Services" href="/docs/sandbox/services" cta="Continue">
    Configure public routes, health checks, and resume behavior.
  </Card>

  <Card title="Snapshot And Restore" href="/docs/sandbox/snapshot-restore" cta="Continue">
    Version and reuse initialized Hermes rootfs state.
  </Card>
</CardGroup>