pi pod runs sessions of the pi coding agent in isolated sandboxes ("pods") on a server you run, in composable environments.
----
Since moving my company towards AI-native work, I have been really frustrated by the state of "agentic engineering" environments. Products by the labs (claude code, codex) lock you into a single provider for your tokens. Agnostic solutions (factory, devin, arguably cursor) make you pay per-token costs. None of these products allow you to fully customize the harness, and of course they all run on someone else's infrastructure.
I've been an early and fervent user of pi, which I think is fantastically simple and beautiful software. I have felt it needs an environment for it to work across platforms with fully functional composability for teams.
This is very much a work in progress, but for my team this has been a much needed solution and has helped us tremendously. I hope you will give it a try and let me know how you would like it to improve.
I'll be sure to check this out but in the meantime, I'd like to ask: Isn't it generally a good practice to run coding agents in a VM? It provides a security boundary so that the agent is restricted to the VM.
How does this compare? I see it's an "isolated sandbox", but what exactly does that mean?
I did that with T3 code.
Hi, I think I might be your target audience, I currently run pi on the server in my basement, in a minimalist docker container that gives it access to my code workspace and a config dir. Give me an idea what benefit I get on top of that by using the self-hosted pi pod?
For you the main benefit would probably be portability via the mobile app. The mobile app is not released yet but you can build it yourself from the swift/kotlin source in the github repository.
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.
I am developing tarvis.io that allows you to self host apps without managing the servers. In addition to that it also comes with cloud dev env where you can do coding and spawn dev servers and you can host same app in your tarvis workspace as a self hosted app. Tarvis takes care of security, storage, backups and ssl domains. Each app auto gets ssl domain and only you can access your apps. Give it a try!
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.
Note: this does not appear to be a Kubernetes-based solution, the "pod" part just heavily sounds like it.
For anyone looking for a Kubernetes-based system, kagent is a good option.
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.
Note: this does also not appear to have anything to do with music playback and having a thousand songs in your pocket.
Yeah, I loved the alliteration with pi but expected this would come at the cost of some slight confusion
With some levity, I'll also add that as a bilingual English/Spanish speaker, my brain seizes a bit at the name. Why? That 'pi' to a Spanish-infected mind pronounces it like 'pea'. Adding 'pod' then naturally takes me to a 'peas in a pod' association. Split-language hall of mirrors. There oughta be a word for this?
Anymore, more a me problem than a name problem. Just wanted to share.
Interesting, thanks, will keep an eye on this
Daily reminder that containers are not considered a safe security boundary, and never were. If you really need to run untrusted code, use a MicroVM.
The barrier to create this myself is so low that 1: I can do it and 2: bad actors can do it. I’d like to use a shared tool that will get iterated on, but I just don’t want to risk it at this point given I can get “good enough” doing it myself.
Is it different than running any harness in an lxc container or vm in your proxmox (or any) server?
The main benefits for using pi pod versus running pi on a server is the native mobile apps and environment composability. The cli experience has also been made really nice with pi pod, the tui is rendered locally so user key input does not lag over the ssh connection.
I use a T3 Code pod in a kubernetes Deployment (sadly no official Docker image), with a PVC so configs and cloned repos survive pod restarts. Seems to work quite well with my Claude subscription (no GPU in my homelab yet)
I use Systemd containers in Nix. That’s really cool because I can selectively link in the parts of my desktop that I want it to have access to.
That all I do. With a vibe coded Python TUI to select and start new instances.
Hi, creator of VibePod here (https://github.com/VibePod/vibepod-cli)
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/
Hi there, creator of Epho here (https://epho.io).
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?
> 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!
[flagged]
[flagged]
[flagged]
Yeah when you self-host pipod, all of your pi sessions are running on your own VM. Within that VM, each pi session runs in its own container.