Lobster Trap: OpenClaw in Containers from Local to K8s and Back

What do you do when an agent looks useful enough to install, but your colleagues warn that it is a security nightmare? For Sally Ann O’Malley, the starting point was familiar infrastructure. At the time of the talk, she described about a decade at Red Hat, with her early work centered on containers, Linux security, Kubernetes and OpenShift. A move into emerging technology broadened what she could experiment with; the subsequent emphasis on AI initially meant a succession of chatbots, Python and Markdown.

During a staycation, Moltbook led her to OpenClaw. She found the project on GitHub, checked its MIT license, built an image, ran it locally in a container and put it on OpenShift. That gave her a concrete application to experiment with across both environments.

Back at work, the response included warnings not to put OpenClaw on a work laptop. Her reaction came from years of working on Linux application isolation: this was an opportunity to apply those controls to an agent. That confidence was a motivation to investigate, not a demonstrated guarantee of safety. There was also a simpler operational reason to use containers: native installations leave dependencies and other files on the host, creating cleanup work after each experiment.

O’Malley calls her persistent personal agent her Forever Claw. Its name is Shubhra, and it has two sub-agents: Joy supplies Jyotish astrology readings and a birth chart, while Bruno delivers daily Boston Bruins briefings. During a close playoff race, Bruno gives her a reason to return every day. These are personal routines attached to an ongoing agent, rather than disposable test conversations.

Asked why it should run in a container, Shubhra produced a list that maps directly onto ordinary application operations:

O’Malley runs across Mac and x86 environments and backs up her Forever Claw nightly. The container supplies a predictable environment; explicit grants determine what it can reach on the host. That reduces dependency drift and host OS surprises, while persistent storage keeps the agent’s continuity separate from the container’s lifetime.

The next examples show what that continuity is for. Joy’s horoscope describes the presentation day as auspicious. Bruno’s briefing discusses Geekie recovering from a lull and the Bruins making the playoffs. Neither requires a cluster, but both illustrate why the accumulated setup and state are worth preserving.

A reusable agent environment includes more than the application image. O’Malley keeps tools, skills and MCP server configuration together in an agent directory and mounts that directory into the container. The pieces are then available at startup, instead of being assembled manually inside each new instance.

Credentials enter through another path. Her local runtime is Podman, and she uses Podman Secrets to store API keys outside the application configuration and deliver them to the container. OpenClaw’s SecretRefs add application-level indirection: a credential field refers to an external source instead of containing the key itself. The reference is configuration; the credential remains a separately managed value. Her motivation is to reduce accidental exposure, particularly keys appearing in logs, and she explicitly describes the arrangement as imperfect. Current OpenClaw documentation makes the boundary precise: resolved credentials still exist in process memory, so SecretRefs are not process isolation.

The cluster equivalent uses Kubernetes Secrets to supply values through environment variables or mounted files, with application configuration referring to those sources. The Secret object does not by itself guarantee encrypted storage: encryption at rest and least-privilege access must be configured. O’Malley packages these choices into her opinionated OpenClaw Installer, a personal tool she makes available for others to try. Its current repository has evolved beyond the version shown in the recording.

The larger deployment pattern begins with agents running across infrastructure and communicating with one another. Once those agents serve business workflows, the requirements become familiar: security, operational control and scale. O’Malley’s approach is the same one she uses for other applications—develop locally, then lift the workload to Kubernetes.

She offers a model-evaluation example from a friend at NVIDIA whom she had met at PyTorchCon. O’Malley reports that about ten engineers each ran OpenClaw in Kubernetes to check on model evaluations periodically; her friend described doing the work of six engineers himself. This is a secondhand account of a workflow, without a defined productivity metric or measurement window. The useful operational detail is the recurring agent activity around evaluations, rather than a person manually checking each time.

For O’Malley, the appeal is that automation leaves more room for creative work. She says she had stopped writing code herself for a few months, after a recent change in her assessment of AI coding tools. Her description of AI as “1,000 times better” at coding than she is was rhetorical self-assessment, and senior Red Hat engineers reacted skeptically. The practical ambition was to spend less effort on tedious implementation and attempt more ambitious projects.

The persistent volume is the recovery boundary. O’Malley keeps all her local runtime state in a Podman volume. Docker also provides volumes; on Kubernetes, a persistent volume claim, or PVC, requests persistent storage for the workload. This is the concrete storage layer behind the earlier backup story: replacing the running container need not mean discarding the agent’s state.

A workplace could use those same packaging boundaries for onboarding. O’Malley imagines a curated baseline OpenClaw issued to each new hire, containing company-approved MCP servers, approved authentication, team-specific skills and access to everyday resources such as Google Drive. The baseline would be distributed across the team, then personalized by each employee.

That proposed workflow replaces a familiar alternative: sit beside a colleague, copy their repository and reconstruct the environment from informal instructions. The baseline carries team standards into a portable setup, while individual instances can develop their own preferences. This is her vision for reproducible onboarding, not a report of an existing company rollout.

Her own persistent agent came after roughly a month of helping with OpenClaw while constantly building, starting and stopping test instances. She describes seeing about 100 new commits an hour and roughly 10,000 commits when pulling after a couple of days—informal observations of rapid upstream churn. A Forever Claw gives her a continuing personal environment alongside that cycle of disposable development instances.

The live demonstration starts by launching the installer’s development server from its project directory:

npm run dev

In her Mac setup, the installer itself runs outside a container because she has not worked out how to have a containerized installer spawn the containers it manages. Linux containers on macOS run through a virtual machine, as documented for Podman Machine, which adds another runtime boundary to arrange. This is an unresolved detail of her setup, not a general prohibition on container orchestration from containers. She also has existing local instances ready in case the live deployment fails.

The local configuration proceeds through a short form:

1. Name the instance. She creates Joe. The form’s choices reflect her own needs, and she invites pull requests for different ones.
2. Avoid a port conflict. Another instance is already running, so she changes the port. She refers to the values aloud as “89” and “99”; the operational point is that the second instance needs a different host port.
3. Select credential mappings. Her Podman secrets already exist on the machine and contain the provider API keys.

The installer brings these choices together rather than requiring her to reconstruct the runtime configuration by hand.

For the installer’s intended Docker path, she explains that exported environment variables become sources for OpenClaw SecretRefs. She recommends using a reference for every credential. This is a distinction between her installer’s chosen paths, not a limitation of Docker: Docker Compose supports file-mounted secrets, and Podman supports both mounted-file and environment-variable delivery.

Next come the providers. She selects OpenRouter because she has been experimenting with Gemma, then chooses Anthropic as a fallback. The form also accepts a custom local endpoint for someone serving a model themselves. Provider choice is therefore another piece of instance configuration, alongside its name, port and credential sources.

Two optional facilities extend the basic instance:

• Observability: The installer can set up an OpenTelemetry collector with Jaeger. O’Malley says this works, but leaves it disabled to avoid taxing the demo machine.
• SSH sandbox: SSH keys and known hosts identify the remote destination where sandboxed commands run. The execution workspace can therefore live away from the local host. Current OpenClaw sandboxing documentation scopes this to supported tools, rather than moving the entire Gateway; the remote workspace is seeded once and is not automatically synchronized back locally.

She deploys Joe, then opens the instances view. A new Podman container is present, and Joe’s gateway logs are available.

The interface also exposes the generated Podman command, making the underlying runtime invocation visible. It is intended to show a Docker command when Docker is selected, but O’Malley explicitly says she has not tested that support; a colleague has offered to try it. In an aside, she credits that colleague, Eric, with an InferRS project that she describes as running Gemma quickly using TurboQuant. No performance measurement accompanies the description.

She opens Joe and selects a status command. O’Malley calls the spin-up “two seconds” and suggests it could have taken one, but the demonstration supplies no measured end-to-end timing or image-cache conditions. What it does show is a transition from the installer form to a running local instance that she can inspect and interact with.

Joe is not the only example. O’Malley switches to Larry, an instance she created through the same form with an MCP server and a sub-agent already configured. The agent view shows Docs Checker and its workspace files. This makes the earlier mounted-configuration idea tangible: the deployed environment can arrive with an agent’s supporting pieces already in place.

The attempted model switch exposes a configuration dependency. She tries to select GPT-5.4, initially unsure of the identifier, then realizes that Joe does not have the extra model configured. She returns to Larry to continue. A model must be configured for an instance before that instance can switch to it. The sequence ends without a confirmed successful switch.

The final view moves from local instances to Kubernetes. The installer is connected to her kind cluster, where Carl is already running and can be opened through the interface. She also describes access to OpenShift instances, with the interface switching to OpenShift when connected there. The closing demonstration establishes access to existing cluster agents, rather than a fresh cluster deployment or a transfer back to the laptop. It completes the operational picture: local and cluster instances are managed through the same style of interface, with configuration, credentials and persistent state treated as explicit parts of the environment.