YHK - yet another hacker news clone

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.

I have a similar project you might be interested in if you use ACP via Zed or something; I need to make a Show HN post at some point.

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/

Yeah, I loved the alliteration with pi but expected this would come at the cost of some slight confusion

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.

im cool with kubernetes not having any exclusive rights over the word "pod"

Kubernetes didn’t invent the word “pod”…

That all I do. With a vibe coded Python TUI to select and start new instances.

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.

https://github.com/pkulak/opencrow

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)

> 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!

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.

What microVM do you recommend ?

It depends on your threat model but I think it's a good reminder either way. I recently discovered SmolVM <https://github.com/smol-machines/smolvm> and it looks like a pretty good sweet spot for usability and isolation. There are so many sandboxing technologies to pick from and understand.

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 think I and lot of others lack a clear instruction how to use it and what are the limitations. With docker/containers we are sold the promise of sandbox (not true, but regardless), and with existing systemd user level separation is really hard to grasp.

A cloud computer is just a VM on someone else computer.