Very interesting! I’ll certainly try it out. I am wondering though what’s the advantage over doing it with a K8s operator (disclaimer, I created and maintain https://github.com/openclaw-rocks/k8s-operator)?
Also, I am genuinely curious about the choice of license.
Given the „new (agentic) way“ in that software is being developed now, don’t you think it can be copied easily and that this kind of license will hinder adoption at some point?
Thanks! The main advantage is simplicity. klaw is a single binary with zero dependencies, no k8s cluster required. For teams already running Kubernetes your operator makes a lot of sense, but most teams we've talked to managing AI agents don't have or want a k8s setup just for that. klaw gives them the same mental model without the infrastructure overhead.
On the license, fair question. The SaaS restriction is narrow, it only prevents someone from reselling klaw as a hosted orchestration service. Internal use, building on it, extending it is all fine. We looked at what Elastic and HashiCorp did and felt this was the right balance for now. Could it slow adoption? Maybe. But we'd rather start here and open up further based on how the community evolves.
OpenClaw is all the hype right now. I played around with it over the weekend and ended up writing a Kubernetes operator for it.
There have been a lot of security concerns around running OpenClaw, and rightfully so. This operator tries to mitigate the ones it can at the infrastructure level: non-root execution, all capabilities dropped, default-deny NetworkPolicy, a validating webhook that blocks root containers. It won't help with what the agent's skills do, but at least the blast radius is contained.
Full disclosure: this was largely vibe-coded with Claude Code. Some highlights of what came out of it:
- Config changes trigger automatic rollouts via SHA-256 content hashing
- Optional Chromium sidecar for browser automation, hardened with its own security context and shared memory tuning
- The whole thing is a single CRD, so going from zero to a secured instance is just a kubectl apply
thanks! Can you confirm it's working now? Apparently, Firefox's Enhanced Tracking Protection blocked the Ahrefs analytics script and the way it was handled ended in some endless loop. Should be fixed now
Yes, good point. I think OpenClaw actually helps here by making a broader audience aware of the security risks of using "unchained" LLMs. Securing a probabilistic system is a fundamentally different challenge than auditing kernel code, and we're all still figuring that out.
I am optimistic that OpenClaw will actually drive a lot of security tooling around the use of LLMs from here
Very silver-lining viewpoint. I suppose that when tens of thousands of users have their identities leaked by well-intentioned helper agents, we will certainly elevate the security discourse. ;)
My personal opinion is that transformer architectures are (by their nature) unsecure. When you pair those with "super duper extremely so-eager-to-help weights and autonomous access to private information - voila! Here we are.
What we need is a pairing for transformers and automation that works natively with them. We're in a post-rules-based world now, so it's going to be something new.
Yeah, I want to be a techno-optimist. But usually we have to go through some valley first before we understand how the technology actually should be handled (I hope that with "social" media we are slowly reaching the end of the valley time).
Author here. I run OpenClaw.rocks, a hosting service for OpenClaw AI agents.
The parallel I'm drawing: LLMs are commoditizing the way x86 hardware did in the early 90s. What's missing is the open-source operating system on top - the layer that connects a token prediction API to your actual tools and messaging apps. That's what OpenClaw does.
I know the analogy is imperfect (and I address where it breaks in the post). Happy to discuss the technical architecture, the agent layer thesis, or where you think I'm wrong.
Realm.fun is a game server hosting platform - think "Vercel for game servers." We make it dead simple to spin up Minecraft, Valheim, Palworld, and 25+ other game servers in seconds.
Stack:
- TypeScript, Astro 5 (SSR), Tailwind CSS
- Supabase (PostgreSQL), Stripe
- Docker, Kubernetes, Pelican Panel
- Deployed on Hetzner Cloud
What you'd work on:
- Building the dashboard where players manage their servers
- Real-time features (console, metrics, player lists)
- Payment/subscription flows
- Infrastructure automation (node provisioning, scaling)
What we're looking for:
- Strong TypeScript skills
- Experience with either frontend (React/Astro) or backend (Node/PostgreSQL)
- Comfortable with infrastructure (Docker, K8s is a plus)
- Bonus: You've actually hosted or played on game servers
Small team, early stage, lots of ownership. We're bootstrapped and profitable.
Apply: https://realm.fun/careers
reply