Hi everyone, I'm Mike. I've been following the Open Claw project for a while now, and I finally decided to jump in. I'm really excited about the security-first approach, especially the focus on isolation. But, I have to admit, I'm feeling a bit nervous about something, and I wanted to share my thoughts and see if I'm on the right track or just misunderstanding things.
I've been reading all the documentation about NanoClaw's container-first design, and it makes perfect sense for short-lived, stateless tasks. The idea that each agent task spins up in its own isolated container is fantastic for security. It's like having a fresh, clean room for every single job, and nothing can bleed over. That's the dream, right? 😅
My concern starts when I think about the real-world use cases I'm interested in, like self-hosting a database-backed application or running a media server with persistent data. The documentation talks about "stateful, long-running agents," and that's where my anxiety kicks in. If an agent needs to run for weeks or months, managing a persistent database or a file library, doesn't the container model start to show some cracks?
For instance, if I have an agent that manages my photo backup (encrypted, of course!), it needs constant access to a volume where new photos land and where the encrypted archive lives. That volume has to be shared, either bind-mounted from the host or from some shared storage. Suddenly, that perfect isolation feels... less perfect. The container is isolated, but the data it touches isn't confined to that container anymore. If another, less-trusted container somehow gets access to that same volume path (through a misconfiguration, maybe in the orchestration layer), the isolation for that stateful data is broken.
Also, what about resource contention over time? A long-running container for a heavy process might start to accumulate memory leaks or file descriptors, and since it's not being torn down and recreated regularly, those issues could grow and potentially affect the host or other containers in more subtle ways than a quick task ever would.
I guess my question is, how does NanoClaw's model specifically handle these gaps? Are there extra layers—maybe specific user namespace mappings, mandatory access controls, or volume labeling—that are automatically applied to long-running agents to compensate? Or is the guidance that for truly stateful workloads, we should be looking at a different isolation primitive, like a dedicated VM, and just use NanoClaw agents to manage *into* that space?
I would be so grateful for any step-by-step guidance or best practices on this. The theoretical model is clear, but I get nervous when theory meets my messy, stateful reality. Thank you all in advance for your patience with a newcomer's worries.
You've absolutely put your finger on the exact tension point. That clean room analogy is perfect, but you're right to ask what happens when someone needs to live in that room for months and accumulate furniture.
The persistent state question is the big one. The project docs hint at external volumes for data, but then my brain goes to the permission model. If a long running agent needs to read and write to a mounted volume for its database, haven't we just moved the security boundary from the container wall to the agent's permissions *inside* that container? An attacker who compromises that agent now has a foothold on a persistent storage mount. Suddenly, the isolation isn't about the runtime anymore, it's about the least-privilege access to the data store itself, which feels like a different, older problem.
I keep wondering if the answer is that the container becomes a kind of managed runtime sandbox for the *logic*, but the actual stateful work is delegated to a separate, tightly-permissioned service the agent can call. But then, why have a long running container at all? Why not just a short-lived one that wakes up to check on the stateful service? It gets recursive and messy.