The artifact is real. The hosted product is not here yet.
Pi pod is an AGPL-licensed repository with a command-line client, server, native sandbox service, iOS source, Android source, and a Docker Compose deployment. The project says the hosted service is coming soon and is not available. Its self-hosted path is the product you can inspect and run today.[1]
We cloned revision 2276084a701edd6b549cfd49624d54223bbf353c. The npm registry returned @pipod/cli 0.1.5 for Node 22.19 or newer. A clean temporary install printed the CLI help and exposed launch, attach, stop, transfer, archive, secrets, settings, jobs, doctor, and dry-run routes. The checked-out CLI also passed its own runtime-surface and TypeScript checks.[4]
A published client proves there is a handle. It does not prove the server, isolation, or recovery path on your host.
Workspace transfer is the first custody decision.
The CLI does not seed every project the same way. For a clean checkout whose pushed remote tip matches HEAD, it clones the exact commit. For dirty trees, unpushed commits, plain directories, and private remotes without usable credentials, it streams a tar archive instead. That archive excludes ignored paths, node_modules, and .pi-pod/env. It can include .git when the repository fits.[2]
That branch matters. Clone mode transfers a named revision. Archive mode transfers a snapshot of local state. Empty mode transfers nothing. Use --dry-run to inspect the decision before creating a pod. Private-remote credentials are forwarded only after approval and are not stored, according to the CLI guide. Confirm that behavior on the release you deploy.
The sandbox and the host are one failure boundary.
The self-hosted stack runs Postgres, Zitadel, the control plane, and the sandbox on one Linux host. The sandbox container is privileged because it mounts overlay filesystems, writes cgroup limits, and creates network namespaces. The Compose file states the host kernel is the isolation boundary.[3]
That is more precise than saying "the agent runs in a container." A container can limit a pod while the privileged sandbox service still depends on the host kernel and operator configuration. Host compromise, a weak kernel boundary, broad credentials, and public exposure remain system questions. A pod shape is not a security verdict.
Self-hosted secrets still have an owner.
The first installation generates deployment secrets. The guide calls out two values that need offline backups separate from database dumps. The Zitadel master key seals identity keys. The secret-encryption key encrypts stored secrets. A restored database is not enough if either required key is gone.[3]
The initial service listens on port 8080 on every interface. The guide says to keep it off the internet until HTTPS and the public route are configured. It also warns that Docker-published ports can bypass host firewalls such as ufw. Local use, tunneled use, and public mobile use are three exposure states, not one setup step.
Recovery has a stop cost.
The upgrade path builds new images, takes database dumps, applies migrations, and checks health. Recreating the sandbox ends live sessions. Workspace files persist on the sandbox volume, so a later attach can resume from those files. That is file persistence, not proof that an interrupted command, process, or external effect can resume safely.[3]
Before adoption, run one launch in each workspace-transfer mode you plan to allow. Stop the sandbox during disposable work. Restore the database and both required keys in a clean environment. Check the public route with a denied user. Then move a file back through the client and compare it with the source. The chain is complete only when the result returns.