Show HN: I built managed OpenClaw hosting with 60s provisioning in 6 days
yixn_io Wednesday, February 11, 2026
Hey HN,
I'm Daniel, solo dev from Germany. I built ClawHosters (https://clawhosters.com), a managed hosting platform for OpenClaw, the open-source AI agent framework.
Quick timeline: domain registered February 5th. First paying customer six days later. I probably should have spent more time on it, but it works.
If you haven't seen OpenClaw, it lets you run a personal AI assistant that connects to Telegram, Discord, Slack, and WhatsApp. Self-hosting it is absolutely possible, but it's a pain. You're dealing with Docker setup, SSL certs, port forwarding, security hardening, keeping the image updated. Most people don't want to deal with any of that. They just want the thing running.
That's what ClawHosters does. You pick a tier (EUR 19-59/mo), click create, and you've got a running instance with a subdomain. About 60 seconds if we have prewarmed capacity, maybe 90 seconds from a cold snapshot.
Some technical details that might interest this crowd:
*Subdomain routing chain.* Every instance gets a subdomain like `mybot.clawhosters.com`. The request path is Cloudflare -> my production server -> Traefik (looks up VPS IP from Redis) -> customer's Hetzner VPS -> nginx on the VPS (validates Host header) -> Docker container (port 18789) -> OpenClaw gateway. All subdomains require HTTP Basic Auth, configured per-instance through Traefik Redis middleware keys. The VPS itself only accepts connections from my production server's IP via Hetzner Cloud Firewall. No way to hit it directly.
*Prewarmed VPS pool.* Even from a snapshot, Hetzner VPS creation takes ~30-60 seconds. That felt too slow. So I maintain a pool of idle, pre-provisioned VPS instances sitting there ready to go. When someone creates an instance, we claim one from the pool, upload the config via SCP, run docker-compose up, done. The pool refills in the background.
*Security is 4 layers deep.* Hetzner Cloud Firewall restricts all VPS inbound traffic to only my production server IP. Host iptables (baked into the snapshot) add OS-level rules with SMTP/IRC blocking. SSH is key-only on both host port 22 and container port 2222, so brute-forcing isn't happening. fail2ban on top of that, and the Docker daemon runs with no-new-privileges. Probably overkill. I'm fine with that.
*SSH into the Docker container.* Users can enable SSH access to their actual container (port 2222). I built a custom image extending OpenClaw with an SSH server, key-only auth, no passwords. Fair warning though: enabling SSH permanently marks the instance as no_support. Once you're installing your own stuff in there, I can't guarantee stability anymore.
*Container commit for state preservation.* This one was tricky to get right. Users can install packages (apt, pip, npm) inside their container. Before any restart or redeploy, `CommitContainerService` runs `docker commit` to save the full filesystem as a new image. Next startup uses the committed image instead of the base one. Basically snapshotting your container's state so nothing gets lost.
I wrote a more detailed technical post about the architecture here: [link to blog post]
The whole thing runs inside a single Rails app that also serves my portfolio site (https://yixn.io). One person, one codebase, real paying customers. I'm happy to answer questions about the architecture, the Hetzner API, or the tradeoffs I made along the way.
Source isn't open yet, but I'm thinking about open-sourcing the provisioning layer. Haven't decided.