ClawHosters
by Daniel Samer
11 min read
Saturday night. Almost eleven. I'm on the couch, beer in hand, some show playing in the background. My phone buzzes. Discord. "Hey Daniel, my bot stopped responding. Can you take a look?"
Sure. I could. Because at this point, I could do this in my sleep.
I'd become the unofficial OpenClaw guy in my friend group. The person you call when your AI assistant stops answering. When Docker complains. When the API keys aren't right. When some port is blocked and nobody knows why.
After a few months of this, I got fed up. And then I thought: "I should just make this a proper thing."
So I did. The result is ClawHosters.com. Managed OpenClaw Hosting. By the way, I also built this site here with Rails. And this is the story of how ClawHosters happened.
The Problem with OpenClaw Setup
OpenClaw is a fantastic project. Over 145,000 GitHub stars and 20,000 forks speak for themselves. Your own AI assistant, running on your own server, working across Telegram, WhatsApp, Discord, and Slack. Sounds great. It is great.
But the setup? That's a different story.
I set up OpenClaw for myself first. Then for my friend Alex. Then for his roommate. Then for a coworker. Then for someone's sister. At some point I'd helped eight people in two months. And every single time, it was the same issues.
Docker conflicts. Port forwarding. API keys. Firewall rules. Updates that break the whole setup. Every damn time the same crap.
I'm not the only one. A developer described pretty much the exact same thing in a GitHub gist: setting it up "can quickly turn into a nightmare, especially if you're not very technical." And even if you are technical, it's annoying.
The pattern was always the same. Someone wants to try OpenClaw. Someone follows the official docs. Something breaks. Someone messages me.
I could fix these problems in my sleep. That wasn't the issue. The issue was that I was debugging config files via Discord screen share at 11pm on a Saturday when I should have been watching my show.
The Moment It Clicked
I think it was around the sixth or seventh setup when it hit me. Wait. I'm doing the exact same thing every time. Same Hetzner server. Docker install. Firewall config. Pull the OpenClaw image. Write the config. Test it. Make sure it survives a reboot.
Why am I not automating this? Automation is exactly my thing – and that's exactly what I did.
I know this pattern. Adam Wathan didn't plan Tailwind CSS as a business. He built utility CSS styles for his own project, showed his work publicly, and people kept asking about it. A side project turned into a multi-million dollar company.
Will ClawHosters be the next Tailwind? Probably not. But the pattern is the same.
That's what I wanted to do.
Building It: Hetzner, Docker, and a Lot of Trial and Error
I'm a Rails developer. Have been since 2016, almost exclusively. For years I've been building custom web applications with this framework.
I built RLTracker.pro, which processed 2.4 million trades. I built Splex.gg, handling 60% of all Splinterlands rentals. I built Golem Overlord, a blockchain game with 20,000 daily players. You can see my full portfolio for more details.
Not bragging. Just explaining why my first instinct was: "I'll build this in Rails."
The Infrastructure
ClawHosters runs on Hetzner Cloud. The choice was easy. Hetzner is solid, affordable, and has a decent API. I've been using Hetzner for years for my own projects.
The basic concept:
A customer clicks "Create Instance." My system automatically provisions a VPS on Hetzner. The server gets set up, OpenClaw gets deployed, and in less than a minute everything's ready.
Sounds simple. It wasn't.
First Attempt: Cloud-init From Scratch
The first version installed everything from zero. Fresh server, bare Ubuntu. Then via cloud-init: install packages, set up Docker, configure the firewall, pull the OpenClaw image, start the container.
It worked. But it took four to five minutes. Pulling the Docker image alone took one to two minutes depending on bandwidth.
Four to five minutes. For a service that promises "1-click deployment"? Forget it.
The Snapshot Approach: Pre-bake Everything
The fix was snapshots. I take a fully configured server, create an image from it, and spin up new instances from that image. Everything pre-installed: Docker, the OpenClaw image, firewall rules, fail2ban, even the Playwright browsers for web automation.
Now the flow looks like this. Create server from snapshot (about 30 seconds). SSH in and upload the specific configuration (docker-compose.yml, environment variables, OpenClaw config). Start the container. Health check. Done.
Under a minute. (I shouted "Yes!" when the first successful test finished. My neighbor knocked on the wall.)
Security: Because Paranoia Is Sometimes Justified
I spent a lot of time on security. Maybe too much. But when Docker security researchers identified over 17,500 internet-exposed self-hosted instances – many of which remained unpatched days after critical fixes – I knew: paranoia has its place.
If a customer's server gets compromised, that's my problem. So I'd rather over-engineer the security than leave gaps.
Every ClawHosters server has iptables with a default DROP policy. That means everything gets blocked unless explicitly allowed. Allowed: SSH (port 22) and the web UI (port 8080). Outbound, I block SMTP and IRC ports so nobody can use the servers for spam or as botnet nodes.
fail2ban locks out after three failed SSH attempts for an hour. Rate limiting against port scans. Docker daemon hardening with no-new-privileges and restricted file descriptors.
Sounds like a lot. It is. But with managed hosting, I carry the responsibility.
What Came Out of It: ClawHosters as a Managed Hosting Solution
ClawHosters.com is live now. Managed OpenClaw Hosting Service on Hetzner infrastructure.
What it does:
OpenClaw instance in under a minute
Telegram, WhatsApp, Discord, Slack
BYOK (Bring Your Own Key) for Anthropic or OpenAI
Full SSH and root access
Automatic updates and maintenance
What it doesn't do:
It's not trying to compete with self-hosting. If you enjoy managing your own VPS, keep doing that. Honestly, more power to you.
It's not a locked-down black box. You get root access. You own your data.
That last point matters to me. I deliberately didn't build a walled garden. Every customer has full access to their server. If you want to leave ClawHosters, you take your data and go. That's it.
What I Underestimated
I'll be honest. I underestimated how much work happens outside the actual tech.
Support Is Its Own Discipline
Customers have questions. Lots of questions. And not always the same ones. Someone wants to know how to connect a Telegram bot to the gateway. Someone else has an issue with the API key format. Another person asks whether WhatsApp still works after a gateway restart.
I underestimated this at first. I figured: "These people are techies, they'll figure it out." Some do. Some don't. And that's fine. That's what the service is for.
The Deployment Pipeline Took Three Attempts
First attempt was too slow (cloud-init from scratch, as I described). Second attempt had a subtle bug. My background job system (Sidekiq) was still holding old code in memory after a deployment. So I deployed new code that was supposed to upload a config file. But the deployment job ran with the old code that didn't have that feature yet.
The result? Instances without the right config. Customers getting a "Pairing Required" error when everything should have worked.
Took me three hours to figure it out. Three hours where I thought: "The deployment went through. What the hell is going wrong?" Until I realized: The job went through. With the old code.
Pricing Is Psychology, Not Math
I wanted to price fairly. The Hetzner server costs are known. On top of that comes my work: maintenance, updates, support, infrastructure. I looked at what competitors charge. And I picked a price I'm comfortable with.
Not a price where I feel like I'm ripping people off. But also not a price where six months from now I'm thinking: "This isn't worth it."
The details are on clawhosters.com.
Why Not Just Self-Host? When Managed Hosting Is Better
Fair question. I have zero issues with people who self-host. I did it myself for weeks. If you enjoy the setup, if you like tinkering with servers, if you want control over every aspect: go for it.
ClawHosters is for the others. For people who want OpenClaw but don't want to deal with Docker, updates, firewalls, and monitoring.
I can change my own car's oil. I don't. Not because I can't, but because I'd rather write code than lie under a car. Managed hosting is the same logic.
DigitalOcean put it well: every hour spent managing servers is an hour not spent on your actual product.
For me personally: I'm a developer. I'd rather build features than administrate servers. ClawHosters lets me offer a service that does exactly that for others.
What's Next
I'm still working on some things. There are features I want to build that aren't done yet. Dashboard improvements. More automation. Better documentation.
I'll share specifics when they're ready.
Right now, I'm at the point where the foundation is solid and the thing works. Customers can sign up, create an instance, and have their own AI assistant running in under a minute. That was the goal. Goal achieved.
The rest comes piece by piece.
The Honest Truth
I didn't build ClawHosters because I had some grand business plan. I built it because I solved a problem for myself and my friends, and at some point I realized: a lot of people have this problem.
Getting the deployment pipeline right took me a while. But now I'm at a point where I'm not embarrassed to share it.
If you want to use OpenClaw without worrying about infrastructure: clawhosters.com.
If you'd rather self-host: respect. Good luck with that.
And if your bot stops responding at 11pm on a Saturday, you now know who to message.
