Containers vs
microVM isolation.
Containers share a kernel. MicroVMs do not. For AI agents that handle credentials and user data, this difference matters.
What container hosting means.
Container platforms (Docker, Kubernetes, ECS, Cloud Run) run your OpenClaw instance as a process that shares the host operating system kernel with every other container on the machine.
Isolation comes from Linux namespaces and cgroups — the same kernel features that power process separation. This is lightweight and fast, but the security boundary is the kernel itself. A kernel vulnerability in one container can potentially reach all others.
For many workloads, this is fine. For AI agents that store API keys, process user messages, and have internet access, the shared kernel is a meaningful risk.
The isolation gap.
Container escape
A vulnerability in the shared kernel (like CVE-2022-0185 or CVE-2024-1086) can allow one container to access the host and all other containers. These CVEs are discovered regularly.
Shared resources
Containers share CPU, memory, and I/O through cgroups. A noisy neighbor can degrade your agent's performance. Side-channel attacks (Spectre, Meltdown variants) remain a concern on shared hardware.
Secret exposure
Kubernetes secrets are base64-encoded, not encrypted. They persist in etcd and can be read by anyone with cluster access. Environment variables are visible in /proc and often logged.
The full breakdown.
| Feature | Container hosting | OmniClaw |
|---|---|---|
| Isolation boundary | Process-level (shared kernel) | Hardware-level (dedicated kernel) |
| Breakout risk | Kernel exploit affects all containers | Requires hypervisor exploit |
| Setup time | 30-60 minutes (Docker + K8s) | Under 60 seconds |
| Monthly cost | ~$20/mo (managed K8s or PaaS) | $0-19/mo |
| CVE exposure | Shared kernel CVEs affect all tenants | Each VM has its own kernel — isolated patches |
| Credential storage | K8s secrets or env vars (base64, not encrypted) | AES-256-GCM encrypted vault, written into the sandbox on request |
| Network isolation | Network policies (often misconfigured) | Own network namespace per VM; traffic between VMs blocked |
| Resource sharing | CPU, memory, I/O shared via cgroups | Dedicated CPU and memory per VM |
| Auto-destroy | Persistent by default | 24h TTL, zero leftover state |
| Updates | Rolling deploys (you manage images) | Automatic, zero-downtime |
| Monitoring | Prometheus, Grafana, etc. (you configure) | Built-in dashboard |
| Data residency | Depends on cloud provider and region | EU (Finland) |
The real cost of containers.
Container hosting looks cheap until you add the infrastructure around it.
| Item | Container hosting | OmniClaw |
|---|---|---|
| Compute | $15-40/mo (managed K8s node) | $0 (free tier) or $19/mo (Pro) |
| Load balancer | $10-20/mo | Included |
| Container registry | $0-10/mo | Not needed |
| Monitoring stack | $0-30/mo (Datadog, Grafana Cloud) | Included |
| SSL certificates | Free (Let's Encrypt) but you manage renewal | Included |
| Engineering time | Ongoing (Dockerfiles, CI/CD, debugging) | Zero |
Which approach is right for you?
Container hosting works when...
- You already have a Kubernetes cluster
- Shared-kernel isolation is acceptable for your use case
- Your team has DevOps expertise
- You need custom networking or service mesh integration
- You are running many microservices and want OpenClaw alongside them
OmniClaw is better when...
- Security and isolation are priorities
- You do not want to manage infrastructure
- You need to be running in minutes, not hours
- Your agent handles sensitive credentials or user data
- You want EU data residency without configuring it
Isolation without Kubernetes.
Every agent gets its own kernel. No Docker, no K8s, no YAML. Just a running OpenClaw instance in 60 seconds.