Lobster Trap: OpenClaw in Containers from Local to K8s and Back — Sally Ann O'Malley, Red Hat

Processed: 2026-05-25 10:18 UTC

Actionable Insights

• Run personal/experimental OpenClaw instances in a container with explicit mounts and secrets. Sally’s practical reason is simple: agent runtimes accumulate tools, skills, MCP servers, logs, and state; containers keep that mess reproducible and bounded. First step: define an image, one persistent runtime volume, and a minimal set of host mounts. Evaluation criteria: can you destroy/recreate the container and recover the same agent state from volume backup; can you list every host path exposed to the agent; can you rotate credentials without editing config files. Caution: a container is not a complete sandbox if you mount the Docker/Podman socket, broad home directories, SSH keys, or host network without policy.

• Use SecretRefs plus platform secret stores; do not pass raw API keys through chat/config. The talk demonstrates Podman secrets and explains the “double pointer” pattern: host/container runtime secret → OpenClaw SecretRef → provider config. For local Podman, inspect with podman secret list; for Kubernetes/OpenShift, use Kubernetes Secrets exposed as env vars or mounted files, then reference those inside OpenClaw. Directly relevant docs/tools: Sally’s installer repo (https://github.com/sallyom/openclaw-installer, final GitHub path currently redirects to https://github.com/sallyom/claw-installer), older Red Hat infra repo (https://github.com/redhat-et/openclaw-infra), and Red Hat’s OpenShift OpenClaw video page. Evaluate by checking that logs/status pages never print raw keys and that deleting/replacing a platform secret rotates the agent credential.

• Create a curated “team baseline” image/bundle, then let individuals personalize above it. The strongest enterprise workflow in the talk is not “everyone runs a pet container”; it is a shared approved baseline with company MCP servers, approved models, auth, default tools, observability, and skills. First step: split config into baseline (agents/, skills/, mcp/, provider policy) and user overlay (memory/, personal skills, per-user secrets). Evaluate onboarding by timing a new hire from zero to a working agent and by diffing their overlay against the baseline. Caution: baseline updates need migration notes, because personal long-lived agents become stateful production-like systems.

• Treat Kubernetes/OpenShift as the scale-out target, not the local starting point. Sally’s local-to-K8s story is a good rollout sequence: develop locally with Podman/Docker, then lift the same image and config model into Kubernetes namespaces/PVCs/Secrets. Try the installer pattern (git clone https://github.com/sallyom/openclaw-installer.git as shown in the repo README, then ./run.sh, open local UI) in a non-production cluster first. Evaluate with namespace isolation, PVC backup/restore, network policy, gateway token management, and per-user resource quotas. Caution: container-in-container is trickier on macOS because Docker/Podman run Linux containers inside a VM; avoid assuming host-level container spawning works the same everywhere.

• Add default-deny networking and observability before calling an agent deployment “enterprise.” The Red Hat page for deploying OpenClaw on OpenShift explicitly mentions default-deny network policies, container-level sandboxing, Kubernetes Secrets, and OpenTelemetry/MLflow tracing. First step: define which egress destinations the agent is allowed to reach, enable trace capture for tool calls/LLM inference/message lifecycle, and create a “break glass” review path for elevated tools. Evaluate by proving you can answer: what did this agent access, which model did it call, which tool mutated state, and which namespace/volume contained the blast radius.

Core thesis

OpenClaw and similar always-on agent runtimes should be packaged like serious infrastructure: reproducible containers locally, Kubernetes/OpenShift for scaled deployments, platform-managed secrets, persistent volumes for memory/state, and curated baselines for teams.

Big ideas / key insights

• Containers make agent state legible. At 2:39–4:43, Sally frames containers as a clean, predictable environment where host access must be explicit.
• Secrets need indirection. At 6:16–7:19, she shows Podman secrets and Kubernetes SecretRefs as ways to keep API keys out of logs and config.
• Backups become a volume problem. At 4:12 and 10:54–11:24, she ties persistent agent memory to Podman volumes/PVCs, which makes backup/recovery operationally tractable.
• Team fan-out is the enterprise pattern. At 11:24–12:57, the talk imagines a company-approved baseline that new hires and teams can reuse, then personalize.
• Local-to-K8s is a workflow, not a slogan. The live demo at 14:00 onward shows an installer UI deploying local Podman instances and switching toward Kubernetes/OpenShift.

Best timestamped moments with interpretation

• 1:38–2:08 — Sally says colleagues called OpenClaw a security nightmare; her counterpoint is that containers/security engineering are exactly how to run risky apps safely. Interpretation: don’t ban agents; bound them.
• 3:40–4:43 — Reproducibility, portability, volumes, backup/recovery, and sandboxing are listed as the reasons containers fit OpenClaw.
• 6:16–7:19 — Podman secrets and OpenClaw SecretRefs are explained. Interpretation: secret handling is a first-class deployment concern, not an afterthought.
• 8:51–9:53 — She cites an Nvidia model-evals use case with OpenClaw running in Kubernetes. Interpretation: agents as periodic infrastructure workers are plausible, but need auditable deployment boundaries.
• 11:24–12:57 — Team fan-out baseline. Interpretation: this is the strongest business use case in the talk.
• 15:04–19:16 — Live installer demo with Podman, provider selection, optional OpenTelemetry collector, SSH sandbox, and status page. Interpretation: the toolchain is moving toward self-service platform UX.

Practical takeaways / recommended workflow

1. Define one local OpenClaw container image and a persistent volume.
2. Move provider keys into Podman/Docker/Kubernetes secrets; configure OpenClaw via SecretRefs.
3. Store agent/team configuration separately from personal memory/state.
4. Back up the volume on a schedule and test restore into a fresh container.
5. Promote to Kubernetes only after local reproducibility works.
6. On Kubernetes/OpenShift, require namespaces, PVCs, NetworkPolicies, Secrets, resource quotas, and traces.
7. For team rollout, maintain a baseline image/bundle and a per-user overlay model.

Comment insights

The comments strongly reinforce that this topic deserves more time. Several viewers asked for a full/extended talk and highlighted security/containerization as important. One comment specifically mentions another Red Hat demo discussing containers and bootc to boot a container with OpenClaw, which suggests audience interest in immutable/container-native host patterns. There is mild pushback that the presentation was “all over the place,” which is fair: the live demo covers many ideas quickly. A “bare metal” preference comment is a useful reminder that containers add operational machinery and are not universally loved.

Deep research on the creator’s main claims

Claim 1: OpenClaw can be deployed reproducibly from local containers to Kubernetes/OpenShift.

Supporting evidence: The active installer repo (sallyom/openclaw-installer, redirecting to sallyom/claw-installer) says it deploys OpenClaw “from your browser — to local containers or Kubernetes,” with ./run.sh and a local UI. The older redhat-et/openclaw-infra repository states it contains scripts/reference material for Kubernetes, OpenShift, and standalone Linux, while noting active work moved to Sally’s installer repo.

Contradicting/cautionary evidence: The older repo explicitly says it is no longer the primary active location. That means operators should verify current commands in the active repo before production use. Live-demo installer UX is promising but not a substitute for cluster policy review.

Claim 2: Containers improve security for agent runtimes.

Supporting evidence: Containers provide process/filesystem isolation, explicit mounts, easier volume backup, and deployment portability. Red Hat’s OpenShift OpenClaw page lists production-grade controls: default-deny network policies for blast radius containment, container-level sandboxing, Kubernetes Secrets, and OpenTelemetry/MLflow tracing.

Contradicting/cautionary evidence: Containerization alone is not a security boundary strong enough for arbitrary tool execution if the container is privileged, has broad host mounts, can access the container socket, has unrestricted egress, or runs with cluster-admin privileges. The correct verdict is “containers are a useful layer,” not “containers make agents safe.”

Claim 3: Secret indirection reduces accidental leaks.

Supporting evidence: Podman and Kubernetes both support secret primitives; OpenClaw SecretRefs add application-level indirection. The active installer README says local deploys inject secrets as container environment variables and reference them from openclaw.json, and Podman deploys can derive those env vars from guided Podman secrets.

Contradicting/cautionary evidence: Environment variables can still leak through process inspection, crash dumps, or overly verbose diagnostics depending on runtime. The safer pattern is least privilege, rotation, and log scanning, not just indirection.

Claim 4: Team baselines can standardize agent onboarding.

Supporting evidence: The installer README describes per-user OpenShell/OpenClaw namespaces and a privilege split: platform-owned OpenShell gateway/sandbox pods versus user/team-owned OpenClaw app namespaces. That supports Sally’s team fan-out concept.

Contradicting/cautionary evidence: Baselines can become stale or over-permissive. They require ownership, versioning, and upgrade/rollback policy.

Verdicts on major claims

• Run OpenClaw in containers by default: Agree, high confidence. For long-lived personal agents, containers plus volumes are cleaner than native installs. Practical takeaway: containerize, but avoid broad host mounts.
• Containers solve the security nightmare: Mixed, medium confidence. They are an essential layer, not a complete solution. Practical takeaway: combine containers with secrets, network policy, sandboxing, quotas, and auditing.
• Podman/Kubernetes secrets plus SecretRefs are the right direction: Agree, high confidence. They reduce accidental exposure and make rotation more manageable. Practical takeaway: never paste raw keys into agent config if a secret ref exists.
• Kubernetes is the right enterprise target: Agree, medium-high confidence. Namespaces/PVCs/Secrets/NetworkPolicies fit multi-user agent deployments. Practical takeaway: use K8s/OpenShift for team scale, but keep local dev simple.
• AI means engineers stop writing code: Mixed, low-medium confidence. Sally says she has not written code in months and AI is better at it; this is plausible as personal experience but overgeneralized as advice. Practical takeaway: use AI heavily, but retain code ownership/review.

Screen-level insights

• 0:38–1:08 — Title slides show “Lobster Trap: Local to K8s and Back” and “Turning one OpenClaw setup into a reproducible baseline,” with a lobster-in-container image. The visual metaphor anchors containerization and reproducibility.
• 1:38 — “The Problem” slide contrasts the “best setup” with what survives: README, YAML, copied keys, verbal instructions. This makes the reproducibility gap concrete.
• 3:10–5:13 — Slides show assistant-generated reasons for containers and personal agents (“Joy,” Bruins briefing). The visuals demonstrate why agent state is personal and persistent, not just stateless CLI output.
• 7:50 — Installer/deploy dashboard shows “This Machine,” Podman/Docker local deployment, agent name fields, owner prefix, display name, and container image. This supports the self-service deployment claim.
• 12:27 — “Team Fan-out” diagram shows a curated OpenClaw baseline branching to engineers/new hires/team platform. This is the most important enterprise architecture frame.
• 15:04–16:09 — Live installer screen shows deployment options and configuration fields; nearby transcript explains local Podman constraints and Mac container-in-VM caveats.
• 16:09 — Terminal output from podman secret list shows provider API keys registered as Podman secrets. This visually confirms the secrets workflow rather than only describing it.
• 19:16 — OpenClaw UI/status screen on localhost shows a live agent session/model/provider status. This confirms the deployment produced a working instance.

My read / why it matters

This talk is valuable because it treats agents as infrastructure, not toys. The strongest idea is the reproducible baseline: if an agent setup includes tools, skills, secrets, memory, models, and sandboxes, then a README is not enough. For Kx’s OpenClaw workflows, the direct application is to maintain containerized, restorable agent environments and to separate baseline config from personal memory/state.

Verification notes

Four review passes were applied before publishing. Source/evidence audit: checked the active installer repo, older Red Hat infra repo, and Red Hat OpenShift video page; claims about commands and repo status are constrained to those sources. Transcript/comment/frame fidelity audit: timestamps and screen claims were matched to extracted transcript and visual frame analysis; comments are summarized as audience signal, not evidence of technical correctness. Hallucination/overclaim audit: softened “containers make it secure” into “containers are one layer” and flagged env-var/privileged-container caveats. Actionable Insights audit: top bullets include concrete rollout steps, links, evaluation criteria, and cautions; residual uncertainty remains around exact current installer behavior because the repo has recently redirected/renamed and production commands should be verified from the active README before use.