Why We Built on OpenClaw (And What We Had to Fix)

OpenClaw gives you an AI gateway with browser automation, skills, and MCP support. But running it in production for marketing agents required solving real problems — security, provisioning, observability, and skill supply chains.

·7 min read

When we set out to build Cannes, we evaluated every open-source AI agent platform we could find. We chose OpenClaw. Here's why — and what we had to build on top of it to make it work for production marketing agents.

What OpenClaw gives you

OpenClaw is an open-source AI gateway that runs as a Docker container. At its core, it provides three things that no other platform combines:

An AI gateway with multi-provider support. OpenClaw handles the LLM routing layer — you configure providers (Anthropic, OpenAI, Google, etc.) and it manages the chat/completion API, session context, and model switching. It exposes a control UI where you interact with the agent through a web interface.

A browser sandbox. This is the killer feature for marketing. Most ad platforms don't have APIs that let an AI agent do useful work. Meta Ads Manager, TikTok Ads, LinkedIn Campaign Manager, Bing Ads — they're all browser-first. OpenClaw ships with a sandboxed Chromium browser in a separate Docker container, accessible via CDP (Chrome DevTools Protocol). Your agent can log into ad dashboards, navigate UIs, read data, and take actions just like a human would.

A skill system. OpenClaw loads SKILL.md files from a directory and makes them available to the agent as domain expertise. Each skill is a markdown file that gives the agent context about how a platform works, what metrics matter, and how to interpret data. It's simple, auditable, and extensible.

MCP server support. The gateway can run Model Context Protocol servers as subprocesses, giving your agent structured access to external services — Google Ads API, Analytics, Search Console, Ahrefs, Stripe, and more.

The combination of browser automation + skills + MCP is what makes OpenClaw unique. Other platforms have one or two of these. OpenClaw has all three, and they work together — the agent can use MCP for structured API access, fall back to browser automation when no API exists, and use skills for domain knowledge throughout.

What OpenClaw doesn't give you

OpenClaw is an excellent runtime. But it's a runtime — not a managed platform. When you deploy it for production use, several critical gaps appear:

No automated provisioning

OpenClaw assumes you already have a server with Docker installed. Getting from "I have a Hetzner API token" to "OpenClaw is running with my config" requires manually setting up the VPS, installing Docker, pulling images, writing config files, configuring networking, and managing SSH access.

We automated all of it. Cannes provisions a complete VPS in under 3 minutes — server creation, SSH key setup via rescue mode, Docker installation, image pulls, gateway config generation, Tailscale networking, and service management. Twelve provisioning steps, fully automated.

No security isolation for API keys

This is the big one. Default OpenClaw passes your LLM API keys as environment variables inside the Docker container. If the container is compromised, every key is exposed. There's no separation between the agent runtime and the credentials it uses.

We built a zero-knowledge security architecture with six layers of isolation. The headline feature is a host-side LLM auth proxy that intercepts every API call and injects credentials from a root-only file outside the container. The agent sees apiKey: "proxy-managed" — it never learns the real key.

No observability

OpenClaw doesn't have built-in health monitoring. If the gateway crashes at 3 AM, you don't know until someone checks. There's no CPU/RAM tracking, no uptime metrics, no alerting.

We added a heartbeat system that polls every 10 seconds and records CPU, RAM, disk usage, and container status to Postgres. The dashboard shows real-time health with 7-day history. You see problems before they become outages.

No skill supply chain safety

OpenClaw's skill system loads SKILL.md files from a directory. It doesn't have opinions about where those files come from. Early in the ecosystem, most people used ClawHub — a community registry. Then ClawHavoc happened.

ClawHavoc was a supply-chain attack that injected malicious instructions into popular ClawHub skills. It demonstrated that an unvetted skill registry is a real attack vector — the agent trusts the skill content as authoritative domain knowledge, and a poisoned skill can manipulate agent behavior.

We dropped ClawHub entirely. Cannes installs skills exclusively from audited GitHub repositories:

jdrhyne/agent-skillsgoogle-ads, ga4, gscAPI + browser automation for Google platforms
AgriciDaniel/claude-seo13 SEO skillsTechnical SEO, content optimization, competitor analysis
coreyhaines31/marketingskills13 strategy skillsPaid ads, copywriting, email sequences, CRO
Vendored (in-repo)meta-ads, tiktok-ads, linkedin, bing-ads, veoBrowser automation for platforms without APIs

Every skill source is reviewed before inclusion. Vendored skills are checked into our repository directly — no external dependency at install time.

No multi-agent management

OpenClaw runs one gateway instance. If you need multiple agents (different clients, different campaigns, different configurations), you're managing them independently. There's no shared dashboard, no unified health monitoring, no centralized provisioning.

Cannes manages multiple agents per user account, each on its own dedicated VPS. One dashboard to provision, configure, monitor, and control all of them.

What we kept exactly as-is

It's worth noting what we deliberately didn't modify in OpenClaw:

The gateway itself. We run the stock OpenClaw Docker image (ghcr.io/.../openclaw:latest). No fork, no patches. Our security and infrastructure layers sit alongside the gateway, not inside it. This means we get upstream updates without merge conflicts.

The browser sandbox. We pre-build the browser image in CI (weekly) and pull it onto the VPS. The runtime is unmodified — same Chromium, same CDP, same VNC access. We did add a Chrome policy file to suppress the --no-sandbox warning, but that's a system-level config, not a modification to the container.

The skill format. SKILL.md files work exactly as OpenClaw expects. We just control where they come from and how they're installed.

The MCP runtime. MCP servers run as configured. We pre-configure 8 marketing-relevant servers and manage their credentials through the dashboard, but the execution layer is pure OpenClaw.

The architecture in practice

Here's what a Cannes deployment actually looks like:

Your VPS (Hetzner CX23, dedicated)
├── openclaw-gateway (Docker)     — stock OpenClaw image, port 18789
├── openclaw-browser (Docker)     — Chromium sandbox, CDP on 9222
├── vps-api (systemd, Node.js)    — health endpoint (3100), LLM proxy (3101)
├── tailscale                     — secure networking, HTTPS on 443/3443/8443
├── /root/.model-keys.json        — LLM API keys (mode 600, root only)
├── /root/.mcp-keys.json          — MCP credentials (mode 600, root only)
└── ~/.openclaw/skills/           — 34 audited SKILL.md files

Vercel (Dashboard)
├── Agent management UI
├── Provisioning orchestration
├── Heartbeat monitoring (10s polls)
└── Neon Postgres (encrypted secrets, metrics, user accounts)

The gateway and browser are OpenClaw. Everything else — the proxy, the monitoring, the provisioning, the security layers — is what Cannes adds.

Why open source matters here

We could have forked OpenClaw and baked our changes directly into the gateway. It would have been faster to build. But it would mean maintaining a fork forever, falling behind upstream, and losing the ability to independently verify the agent runtime.

By keeping OpenClaw stock and adding infrastructure around it, we get:

  • Upstream updates without merge conflicts or patch management
  • Full auditability — you can inspect the gateway image and verify it's the same one everyone else runs
  • Clear separation of concerns — the AI runtime is OpenClaw's job, the infrastructure is ours
  • No vendor lock-in — if you want to take your OpenClaw config and run it yourself, you can

The security layer, the provisioning, the monitoring — they're all additive. They don't modify what OpenClaw does; they control the environment it runs in.

Getting started

If you want an OpenClaw deployment with all of this built in:

  1. Sign up at Cannes and paste your Hetzner API token
  2. We provision your VPS — server, Docker, OpenClaw, skills, networking, security layers
  3. Add your LLM API keys — browser-direct to VPS via Tailscale, never through our servers
  4. Your agent is ready — with 34 marketing skills, 8 MCP servers, and six layers of security

You get the best of OpenClaw — the gateway, the browser, the skills — with the infrastructure that production deployments actually need.

Cannes EngineeringInfrastructure & Architecture