Container Images Turn OpenClaw Setups Into Reproducible Team Baselines

Sally O'Malley’s central claim is that a good OpenClaw setup should not be passed around as a fragile collection of README instructions, YAML, copied API keys, and “just ask me” context. It should become a reproducible baseline: the same image, the same curated agent bundle, the same conventions, and environment-specific plumbing for secrets and state.

O’Malley framed the problem from the perspective of someone who had spent years on containers, Linux security, Kubernetes, and OpenShift at Red Hat before moving into emerging technology work. When OpenClaw appeared, she treated it like an application she could containerize: build an image, run it locally, put it on OpenShift, and see what the operational shape looked like.

That put her at odds with some initial reactions inside Red Hat. When she told colleagues to try OpenClaw, some called it a security nightmare and warned against putting it on a work laptop. Her answer was not that OpenClaw needed to be trusted by default. It was that taking applications and running them securely is what the container and enterprise Linux stack is for. “If we can’t take an application and run it securely,” she said, “come on.” For her, OpenClaw was an opportunity to apply the same isolation, reproducibility, secrets handling, and deployment practices to agents that teams already apply to other workloads.

The slide describing the problem made the split explicit. A strong local setup can contain the right models, approved tools and skills, a safe runtime boundary, and clean secret handling. What usually survives when someone else tries to reproduce it is much weaker: a README, some YAML, copied API keys, and informal help from the original author. The point of the containerized approach is to move the agent setup from personal craft to something a team can actually reuse.

O’Malley’s preferred artifact is a curated bundle. That bundle can include pre-structured agent directories, skills, Model Context Protocol configuration, naming conventions, workflow standards, and model choices across providers such as Anthropic, OpenAI, Google, OpenRouter, or self-hosted open-source models. The bundle becomes the baseline; the deployment flow makes that baseline repeatable across local machines and clusters.

O’Malley said running applications natively feels foreign to her because it leaves files and dependencies scattered across the host. Containers give her a clean runtime boundary: tools, dependencies, model configuration, files, and mounted directories can be made explicit.

She asked her own “Forever Claw” why it should run in a container, and the answer shown on the slide listed the same infrastructure properties O’Malley emphasized throughout: reproducible environments, secrets isolation, portability, restart behavior, volume-backed persistence, faster updates, and a security boundary. The on-screen text summarized the agent’s stance this way: “The walls aren’t a cage — they’re a workshop.”

That phrasing captured O’Malley’s view. The container is not only a deployment package. It is a predictable workshop in which an agent’s tools can work reliably without depending on host OS quirks or stale dependencies. It also forces the operator to be explicit about host access. In her setup, a container can be given a whole agent directory at startup — tools, skills, MCP servers, and workspace structure — by mounting that directory into the container. The result is an OpenClaw instance that comes up with the expected capabilities already in place.

She also made the local examples deliberately personal rather than enterprise-only. Her “Forever Claw” includes sub-agents: Joy, a Jyotish astrology agent that gives weekly readings and birth-chart interpretations, and Bruno, a daily Boston Bruins briefing agent. Those examples were playful, but they were also demonstrations of persistence and personalization. The same runtime pattern that lets her maintain an astrology agent and a sports briefing agent can also carry a company’s approved MCP servers, team skills, and authentication conventions.

The security argument is container-native. O’Malley pointed to non-root execution, no implicit host access, exec approvals, network isolation, and explicit mounts as the kinds of boundaries a containerized OpenClaw can use. She did not describe the setup as perfect. She described it as a familiar operating model: a sandbox whose permissions are made visible and controlled.

The most concrete security mechanism in O’Malley’s setup is secret indirection. Locally, she uses Podman rather than Docker, in part because Podman has a secrets feature she likes. API keys can be saved as Podman secrets and mounted into the container at runtime. OpenClaw then adds its own SecretRef abstraction inside the application.

That means the OpenClaw configuration does not need to carry raw API keys. The API key is represented as a pointer to a SecretRef, which points outward to the runtime secret. O’Malley described this as “a double” separation: the host has its secret backend, and OpenClaw has its own reference layer.

She was careful not to overstate the guarantee. “That’s not perfect,” she said, but it gives her peace of mind that API keys are not casually appearing in logs and configuration output. In Kubernetes, she uses the same conceptual pattern with a different backend: Kubernetes Secrets are injected as environment variables, and OpenClaw still sees a SecretRef abstraction.

The slide on secrets divided the system into two environments:

In the live demo, her installer showed Podman secret mappings for Anthropic, OpenRouter, and OpenAI keys. A terminal command, podman secret list, displayed several named secrets already present on her system, including openrouter_api_key, anthropic_api_key, maas_api_key, gemma_api_key, and openai_api_key. In the installer form, those names were mapped to target environment variables such as ANTHROPIC_API_KEY, OPENROUTER_API_KEY, and OPENAI_API_KEY.

For Docker, O’Malley said the installer is intended to work by taking exported environment variables and turning them into OpenClaw SecretRefs. She acknowledged that the tool has Podman “written all over it” and that she had not personally tested Docker support, though a Docker-employed friend had offered to try it. The important part of the architecture, in her view, is not the specific local engine. It is the separation between raw credentials and the agent’s configuration.

O’Malley’s local-to-cluster story is deliberately simple: use the same image, the same curated bundle, and a different secret backend. That is “the whole migration,” as the slide put it. Local deployment uses Podman secrets; Kubernetes deployment uses an openclaw-secrets Kubernetes Secret. The OpenClaw home directory and runtime configuration remain structurally consistent.

This matches her broader workflow. She said she develops locally and then lifts workloads to Kubernetes, and she expects AI workloads and agents to follow the same pattern as other applications. If agents are going to run everywhere and communicate with one another, especially in business contexts rather than personal astrology or sports updates, teams need the same answers they need for any application: how to secure it, how to operate it at scale, and how to standardize deployment.

The installer she demonstrated exposes that model directly. It has two deployment targets: “This Machine,” which runs OpenClaw locally with Podman or Docker, and “Kubernetes,” which deploys to a connected cluster. In the demo, the Kubernetes target was connected to a local Kind cluster. O’Malley also said the tool switches over to OpenShift if the user is connected to OpenShift.

The same image appeared throughout the flow: ghcr.io/openclaw/openclaw:latest. The local command generated by the installer was a podman run invocation with restart policy, port mapping, labels, a host directory mount, a named volume for OpenClaw runtime data, and secret mappings. In the displayed command, the container ran the OpenClaw gateway with node dist/index.js gateway --kind lan --port 18799.

That command is the operational argument in miniature. The agent is no longer an opaque personal setup. It is a reproducible run command: image, ports, labels, mounts, runtime data, secrets, and process entrypoint.

O’Malley also showed Kubernetes instances in the installer’s instance list alongside local instances. One agent, Karl, was running in Kubernetes and accessible through the OpenClaw chat UI. The Kubernetes instance surfaced an approval requirement for a tool command, demonstrating that the cluster deployment still participates in OpenClaw’s approval and control surfaces rather than becoming a separate operating mode.

O’Malley’s persistence model separates the reproducible input from runtime state. The curated agent bundle is the input: skills, conventions, configuration, model routes, and workspace layout. The state lives in a storage primitive attached to the deployment.

Locally, that state lives in a Podman volume mounted at /home/node/.openclaw. In Kubernetes, it lives in a PersistentVolumeClaim mounted at the same path. The point is that the OpenClaw home directory stays consistent while the storage backend changes with the environment.

That gives backup and recovery a clean shape. For a local deployment, archive the Podman volume, restore it into a new Podman volume, and move the setup to another machine if needed. In Kubernetes, snapshot or copy the PVC, restore it into a new deployment, and keep the same OpenClaw home directory structure.

O’Malley said she backs up her own Forever Claw every night using a scheduled service on her Mac. The emotional phrasing — “I love my Forever Claw” — sat next to a pragmatic operational point: if the runtime state is isolated in a named volume, backup and recovery stop being special procedures. They become commands.

The volume model also matters for team distribution. A baseline can be shared without making every user share the same state. An organization can provide a standard image and curated bundle, while each engineer or namespace gets its own secrets and runtime storage. That distinction is what lets the baseline be common without erasing individual customization.

O’Malley’s workplace vision is a standardized OpenClaw baseline that new hires and existing engineers can start from immediately. The baseline would include approved MCP servers, company-approved authentication, team-specific skills, and common integrations such as access to shared work systems. From there, individuals can personalize their own agents.

The alternative, in her framing, is the familiar onboarding pattern: a new hire sits next to someone, copies a repo, reads scattered instructions, and assembles the environment by hand. The containerized baseline turns that hard-won local knowledge into a team asset. The slide summarized the value as reproducible onboarding, portable environments, shared team standards, and “a starting point, not a cage.”

This matters because the baseline is not meant to freeze the agent. It is meant to give everyone a working floor. Engineers can fork it, extend it, add custom tools, or change the model configuration. The shared artifact handles the boring and risky parts: conventions, approved defaults, runtime structure, and known-good deployment.

O’Malley connected that vision to an example from Nvidia that a friend allowed her to share. According to her, an Nvidia team is running model evaluations with OpenClaw. Around ten engineers each have their own OpenClaw running in Kubernetes, periodically checking in with model evals. She said her friend described the setup as doing the work of six engineers with himself.

She immediately pushed back against a job-loss interpretation. Her claim was not that AI agents eliminate the need for engineers. It was that they move engineers away from tedious code and toward more creative, exploratory work. She said AI has allowed her and her team to “dream bigger,” and that she had recently told her organization that people not using AI for everything were missing out. Some senior Red Hat engineers raised eyebrows, she said, but her own conclusion was blunt: for many coding tasks, the AI was “1,000 times better” than she was.

That statement was personal testimony rather than a benchmark, but it explained why she cared about packaging agents correctly. If teams are going to rely on agents for real work — model evals, code support, operational tasks, domain-specific workflows — the setup cannot remain tribal knowledge.

O’Malley’s installer is opinionated and personal by design. She said she built it for herself, with exactly the options she needs, and is not pushing it on anyone. It is available on GitHub as openclaw-installer, and she invited people to use it or submit pull requests if they want changes.

The demo began with the local path. The installer runs as an npm run dev application. O’Malley noted one irritation: on her Mac, she was not currently running the installer itself in a container because spawning containers from inside a container is awkward on macOS. She explained that containers run on Linux, so Docker or Podman on a Mac runs inside a virtual machine. That extra virtualization layer complicates container-from-container workflows, whereas on Linux the pattern is more straightforward.

She created a local OpenClaw instance named Joe. The form included an agent name, owner prefix, display name, container image, local gateway port, extra Podman or Docker run arguments, and Podman secret mappings. Because she already had other instances running, she used a non-default port. The installer generated and executed the Podman command.

The resulting instance appeared in the installer’s Instances tab alongside another local instance, Larry. The UI exposed logs, connection information, the generated command, stop controls, and delete-data controls. O’Malley opened Joe in the OpenClaw chat interface and ran status commands. The status output showed OpenClaw version 2024.4.0, the model route openrouter/google/gemma-4-20b-ai-it, an API key source of OPENROUTER_API_KEY, OpenAI-compatible endpoints, and runtime data at /home/node/.openclaw.

She configured OpenRouter as the primary provider, using a Google Gemma model, and Anthropic as a fallback. The provider section also allowed local endpoints for self-hosted models. The installer could expose OpenAI-compatible API endpoints such as /v1/chat/completions, /v1/responses, and /v1/models.

The form also included optional observability. O’Malley, who said she works on observability, added a checkbox to run an OpenTelemetry Collector sidecar that can export traces to Jaeger, MLflow, Grafana Tempo, or another OTLP-compatible backend. She said it works and is “awesome,” but declined to enable it during the demo to avoid taxing her machine.

Another optional feature was the OpenClaw SSH sandbox. O’Malley described it as a backend where the user provides SSH keys and known hosts for a target environment, and OpenClaw runs commands in that workspace. She called it “super cool,” but again did not dwell on it because of time.

She intended to show model switching and preconfigured sub-agents, but the live demo ran into the normal constraints of a short talk. Joe did not have the extra model setup she wanted to show, so she switched attention toward Larry, an instance she had started with an MCP server and sub-agent through the form. The incomplete path still reinforced the broader claim: the installer was not merely documenting the setup. It was creating named, running OpenClaw instances with explicit model, secret, volume, and runtime configuration.