121 points | 6d ago | Discuss on Hacker News | Back to Radar
Anymore, more a me problem than a name problem. Just wanted to share.
https://kagent.dev/docs/kagent/0.x/concepts/agents/
It offers various abstractions for running agents in your cluster. It can be defined with simple inline text, or be your own agent image such as one that contains pi. It adds lots of useful features like APIs, UI, observability and Substrate integration.
This looks very interesting, letting people run these in any box they own. I very much agree with the sentiment that there are no proper tools that let you run any coding agent without being locked to a single provider. I just want to run opencode or pi somewhere in a box without having to spin up all of them in my machine, let alone being able to trigger them from within another prouduct as a background agent.
Would pi-pod allow me to standardize pi config on a team/project level so that other people in my org can also use them on the same private infra?
Yep!
How does this compare? I see it's an "isolated sandbox", but what exactly does that mean?
I spent lots of time on this topic, and had a similar path. Meanwhile the tool also supports a quick way to add custom or local providers to agents: https://vibepod.dev/news/vibepod-cli-0-24/
firecracker is a lot more of a headache to setup than docker sbx (not container!) but if you can get it going it probably “feels” the best
of a different variety some people feel better using stuff like bubblewrap/fire jail but idk if these are still microvm as opposed to the above
but it’s my opinion (perhaps completely criticizable), that sandboxing for personal home use machines is 1) somewhat overkill 2) somewhat theatre 3) psychologically sometimes exhausting and unrealistic always assuming the worst is going to happen and 4) not really worth the time and creates quite a bit of friction that there wasn’t previously. In the end I spent more time tinkering with the sandbox to get it “just” right that it drained my time actually using the agents so …
I've been using (rootless) Podman which gives me some basic assurances that it will stay in its designated directory and not run tools on my system directly but I have no limits on the network and with an internal UID/GID of 0:0 I have not done myself any favours. This is the same level of protection one would implement to keep a poorly written bash script from wreaking havoc and that's about it.
I focus on being the batteries-included approach for microVMs. So network is off by default, and you can allow specific hosts (DNS is filtered too), so an agent can reach its model API and nothing else.
And then I also put a lot of work in the jailer-style hardening around the VMM process itself: seccomp allowlist, Landlock, separate unprivileged uid per VM, and cgroup limits.
So that users have security & knobs right out of the box.
fwiw i used to operate an AWS service using firecracker.
gVisor felt a bit more "hacky" initially (at least compared to krun) but I will look into it a bit more as I saw someone else integrating it into their own setup.
My goal is to get 80% of the isolation for 20% inconvenience. Right now it feels like I'm getting 30-50% isolation for 10% inconvenience — I'm willing to tolerate a bit more friction if I can get a bigger jump in security.
To be fair: I support sandboxing and microVMs.
I'm pretty sure there's thousands of us, all implementing our own harnesses. The era of truly personal computing!
It's definitely more manual than some other solutions, but I prefer to know what my agents want to do before they do it.
It's not exactly isolated in their own VMs though. It's using Docker which isn't the safest solution out there but also... well, it is what it is.
So I've been experimenting for these purposes with omnigent as a way to be less locked into a single provider and for its sandbox abstraction. And I've also tried openshell for sandboxing. Hoping those two will keep improving.
it has all the options you would ever want, and is actually deeply aware of the kernel capabilities.
every day someone comes with a new sandbox solution because they are too lazy to read one page documentation.
Comments are loaded live from Hacker News and are not stored by Mid or Real.
ineptech 6d ago on HN
edverma2 (author) 6d ago on HN
Otherwise, the main benefit here is for people to be able to clearly define all of their pi and agent config at the org, user, and project level. This most directly benefits teams of people working together, but I also find it helps me as a single user working on multiple projects on multiple devices.
scottydelta 5d ago on HN
I am running deepseek harness as self hosted app on tarvis for myself. You can run pi as self hosted harness there too by telling the agent to set it up and then access on the go from the browser.
everforward 4d ago on HN
The gist is that it pretends to be an ACP agent to Zed, but it actually spins up a Docker container on your PC and proxies the ACP connection over websocket to the agent. It supports bind-mounting your Pi config like you're doing (as well as copying files, so changes don't propagate to your host). It also has early plugin support for your ACP connection. It's basically an nginx proxy for ACP, I just made a plugin that will automatically kill a session if it detects OpenRouter secrets in agent output, tool calls, file access or shell commands.
It doesn't currently support remote targets like your server, but it's on the list.
Another notable difference is that it creates a new container every time you connect so you get an idempotent environment, though I am also working on a persistent style. Everything supports it, I just need to make the host-side binary support finding a container to use before it tries starting a new one.
https://abyss.scurry.io/