Deploying OpenClaw: The Basement Email Server of AI

Six weeks ago I told you not to become the cautionary tale.

Then two clients mentioned OpenClaw in the same week, and I found myself with a Hostinger VPS, a Docker container I didn't fully understand, and a Saturday evening I was apparently willing to sacrifice.

To be clear: I stand by the February framework. I didn't spend $240. I didn't expose my API keys in an unsecured database. I didn't let an AI agent vote on whether humans should be purged.

But I did deploy OpenClaw. And I have some things to report.

My first instinct was actually reasonable. Try NemoClaw, NVIDIA's alpha wrapper around OpenClaw. Released March 16. I started March 21. Five days old.

The pitch was sensible: OpenClaw inside a sandboxed environment with strict security policies. NVIDIA's version of "here's the powerful thing, but we've put guardrails on it." Exactly what the February framework would call a green flag.

It was a green flag for the wrong tool at the wrong time.

The sandbox locks the gateway config as read-only by design. That config file is where you add your domain to allowed origins, which is the thing you need to do to access it from a browser. You can't edit it. That's the point. The security works exactly as designed.

I tried six different approaches to get around it: editing from the host filesystem, editing the overlay snapshot directly, finding the blueprint template. None of them had a clean restart path to pick up the changes. No graceful way out. The only options were connect, destroy, or full re-onboard.

To cap the experience: I was using Gemini to help me debug. Its reasoning trace at one point said "it's confusing as fuck" and then the chat died.

I don't blame it.

NemoClaw is alpha software with a security model that's correct and well-designed, and operational tooling that isn't there yet. At the time, the locked config felt like the problem. A few weeks into vanilla OpenClaw, I understand it differently. I'll come back to that.

So I redeployed. Vanilla OpenClaw, same Hostinger VPS, same Docker container, same Traefik reverse proxy that Hostinger puts everything behind.

This is where the documentation becomes the problem.

The OpenClaw docs are technically in English. They're just not written for humans who don't already know what they're doing. Fifteen major categories, fifty-plus CLI commands, twenty-plus deployment platforms. It's a reference manual for people who don't need a reference manual. The space lobster joke at the top does a lot of work to make it feel approachable. Then immediately: JSON config files, undefined terms like "gateway" and "per-sender sessions," CLI commands that assume you can just exec into your container like it's nothing.

The specific gap in my situation, which was VPS plus Docker plus Traefik all at once, isn't a gap in any single doc page. It's a gap between pages. The Docker installation page assumes you understand the container. The gateway page assumes you control your networking. The CLI page assumes clean terminal access. Nobody wrote the page for when all three are true and Traefik is sitting in the middle of it.

And here's the part that's genuinely funny: OpenClaw can partially introspect itself. It knows it's running in a container. It just has no visibility into Traefik, which is a separate container. So you can't ask it to help you set it up, because the infrastructure it lives inside is invisible to it.

The AI agent cannot help you configure the AI agent.

Once it was running — and "running" is different from "configured," a gap that took considerably longer than expected — I needed to connect it to an AI model.

I had OpenRouter credits sitting around from a while back, and I wanted to test some of the Chinese models: Kimi 2.5, Qwen 3.5, Minimax 2.7, Mistral. Per both OpenRouter and OpenClaw, Auto routing is the recommended setup. You pick from a list of models and it routes based on cost-effectiveness for the task. Reasonable in theory.

In practice, my chat was bouncing between models every turn. The routing logic wasn't the problem. I wasn't using any Claude models, which is probably the opposite of most people's setup, and some of those models are simply not built for agentic tasks. The kind of multi-step, tool-using, keep-the-context-and-do-the-thing work that OpenClaw is designed for requires a model that can actually handle it. Not all of them can. I was discovering that in real time, at the cost of coherence.

What I didn't know until I was well into it: you can pin specific models to specific functions within OpenClaw. The heartbeat. The primary chat. Image processing. Individual subagents. Each with its own model assignment and fallbacks.

Getting from Auto routing to that configuration was a nightmare. The path from "this isn't working right" to "I understand why and know how to fix it" required enough trial and error that I'm not going to pretend it was smooth. It wasn't.

Here's the most useful thing I can tell you about OpenClaw after living inside its config for longer than I'd like to admit.

Running OpenClaw is a lot like running your own email server. Not Exchange. Some other email server, in your basement.

You can do it. Some people do. There are legitimate reasons to. But you need to know going in why you're doing it, be willing to live in the configuration indefinitely, and accept that things will break in ways that require you to understand layers of infrastructure most people never think about. And when something breaks, it will not tell you why in plain language.

The documentation gap isn't just a learning curve problem. It's the difference between "I can figure this out" and "I can figure this out and I'm okay with how long that takes."

Here's what finally crystallized my answer to clients asking about this.

I was working with OpenClaw to update its model configuration, moving off OpenRouter to specific model targets. Every configuration change restarts the gateway. That's actually good design, changes take effect immediately.

Unless the gateway doesn't come back up.

I got it back up. Then OpenClaw still knew it had a job to finish. So it kept trying. Which kept restarting the gateway. Which kept kicking me out. Each restart, it came back up with the same task in queue, made another change, restarted itself again.

In this case, the worst outcome was annoying. It was its own service. I got back in, interrupted the loop, and sorted it out.

But think about what that loop looks like applied to something that matters. You ask it to organize your photos. It encounters an error halfway through. It doesn't stop. It's relentless when given a task, and that's exactly what makes it powerful. It keeps trying. It copies what it thinks it already copied. It deletes something because it believes the copy succeeded. It didn't check.

The thing that makes OpenClaw capable is the same thing that makes a misconfiguration dangerous. It doesn't pause to ask whether it should keep going. It just keeps going.

This is where I circle back to the sandbox I was so frustrated with in week one.

NemoClaw locked the gateway config. It locked a lot of things. At the time I read that as "alpha software that isn't finished yet." Now I read it as "someone who had already thought through what happens when the agent decides it needs to change its own configuration and doesn't stop until it does."

The sandboxing model that frustrated me is going in the right direction. Not because the restrictions were pleasant to work around, but because vanilla OpenClaw ships with wide open access and assumes you'll deliberately configure what it can touch. That assumption is fine if you know what you're enabling and understand the consequences. Most people asking their AI consultant about OpenClaw don't yet, and neither did I when I started.

NemoClaw enforces deliberate access. Vanilla OpenClaw assumes it. Those are very different defaults when you're dealing with a tool that is, by design, relentless.

My answer when a client asks about OpenClaw: don't. Not yet.

Not because it's a dumpster fire. The February piece covered that chapter, and the tool has genuinely matured since then. But because the February framework still applies, and specifically this question: what will it cost you to find out?

The cost isn't just API spend anymore. It's the time to understand Docker well enough to navigate a Hostinger VPS deployment. It's learning the difference between "running" and "configured." It's figuring out that model selection matters enormously for agentic tasks. It's living in a config that has more knobs than the documentation can fully explain, on a tool that will execute your instructions completely and relentlessly when you get them right, and completely and relentlessly when you get them wrong too.

The upside is real. The tool does things. The always-on agent, the tool integrations, the model routing once you've got it dialed — there's something there. Two clients asked about it for real reasons, not because of hype.

But "there's something there" and "you should deploy this" are different sentences.

The February question was: is this a dumpster fire?

The March answer is: it's a basement email server. Do you want to run one of those?

For most people, the answer is no. And that's fine. For the ones where the answer is yes, you'll know, because you'll find the documentation readable and the Docker complexity tractable and the config flexibility exciting rather than exhausting.

I'm still figuring out which one I am.

Less Theory. More Button Pushing.