OpenClaw is where Spinup started
OpenClaw was the first harness on the platform. Persistent environments, secrets projection, snapshot restore, and harness portability were all built and validated against OpenClaw before anything else. It remains the reference implementation.
What Makes OpenClaw Different
A full agent runtime, not a thin model wrapper
OpenClaw has its own state layer, configuration system, and resource requirements. A generic sandbox overlooks most of those details. The runtime needs to understand how OpenClaw actually works.
Managed installation and execution
Each agent run is a self-contained CLI invocation. The runtime handles installation, dependency management, and process lifecycle so your team never touches Node toolchains.
Built-in session continuity
Multi-turn conversations maintain context across runs. The agent's state persists between invocations, so it picks up where it left off instead of replaying from scratch.
Right-sized resources per harness
OpenClaw's runtime stack (Node, SQLite state layer, and the agent process) needs more headroom than lighter harnesses. Spinup allocates the right resources per harness automatically.
Zero-setup configuration
Spinup projects all required configuration into the environment automatically. Config validation runs before the first execution, catching misconfigurations early rather than mid-run.
Reference Implementation
How OpenClaw shaped the Spinup runtime
Every runtime makes design decisions based on the first real workload it supports. For Spinup, that workload was OpenClaw. The need for persistent state led to the snapshot model. The need for secure credentials led to secrets projection. The need to catch broken configs early led to harness lifecycle hooks.
OpenClaw runs on Spinup with the same semantics it has locally, but inside an isolated environment with managed secrets, controlled network access, and persistent state. The runtime handles what the harness does not: isolation boundaries, environment durability, and operational controls that work across harnesses.
Because OpenClaw came first, every harness that follows inherits the same runtime primitives. The team did not design abstractions in theory and then apply them. They extracted them from making OpenClaw work in production, then generalized.
FAQ
Common questions about running OpenClaw on Spinup
What does it mean that OpenClaw is Spinup's reference harness?+
OpenClaw was the first harness integrated into Spinup. The runtime primitives (environment isolation, secrets projection, snapshot restore, harness lifecycle) were all designed and validated against OpenClaw before any other harness existed. That makes it the reference implementation, not just one option in a list.
Why does OpenClaw need more resources than other harnesses?+
OpenClaw's runtime stack (Node, SQLite state layer, and the agent process) needs more headroom than lighter harnesses. Spinup allocates resources at the harness level, so OpenClaw gets the memory it requires without starving other agents on the same account.
How does session continuity work for OpenClaw on Spinup?+
OpenClaw supports both single-turn and multi-turn execution. For multi-turn conversations, Spinup preserves the agent's session state across runs so it can pick up where it left off without replaying the full history. This works because the environment persists between runs.
Do I need to configure OpenClaw manually inside the environment?+
Spinup projects all required configuration into the environment automatically. You do not need to set up config paths, state directories, or runtime flags by hand. The runtime validates configuration before the first agent execution to catch issues early.
Related
OpenClaw fits inside a broader runtime model
The runtime stays stable above the harness layer. These pages cover the primitives that OpenClaw, and every other harness, depends on.
Early Access
Start with the reference harness. Keep the runtime portable.
Join the early-access waitlist if this is the runtime shape your team has been missing.