Pi Coding Agent VPS Hosting — Self-Host Pi on a Server

Why run Pi on a server

• Sessions that outlive your laptop. Pi saves every conversation automatically. pi --continue reopens the latest session for the working directory and pi --resume opens a picker, so you can close the lid, reconnect from another machine and carry on.
• Long jobs and scripts. Print, JSON and RPC modes let a cron job or CI step run Pi with no terminal attached.
• Any model. Pi supports subscription sign-in and API keys across many providers, so a server can run it against whichever provider you already pay.
• A boundary you choose. Pi has no sandbox of its own. A disposable VPS or a container on one keeps your laptop, SSH keys and browser profile out of its reach.

This page is about self-hosting. For what Pi is, model selection and the extension system, read the main Pi coding agent guide.

What the server needs

Pi's docs require Node.js 22.19 or newer for the npm install, and say the official installers can provision Node.js if it is missing. They publish no RAM or CPU minimum. Pi only sends requests to a model provider, so there is no GPU requirement; the load that matters is your own project: package installs, compilers and test suites that Pi starts through its bash tool. Start with a 2 vCPU / 4 GB plan and resize if your builds are heavy. Keep SSH as the only open port, because none of Pi's documented interfaces listens on the network.

Set up Pi on a VPS, step by step

1. Create a dedicated non-root user

Pi acts with the permissions of whoever starts it, so never run it as root. Create a user that owns nothing but the code you want Pi to work on:

adduser pi-agent
# add your SSH public key to /home/pi-agent/.ssh/authorized_keys
ssh pi-agent@your-server

2. Install Pi

The documented installer for Linux and macOS is:

curl -fsSL https://pi.dev/install.sh | sh
exec bash -l          # reload so the new PATH entry applies
pi --version

Pi's quickstart says the installer pins all dependencies and that you update with pi update. The alternative is npm, which does not pin transitive dependencies and needs Node.js 22.19 or newer:

npm install -g --ignore-scripts @earendil-works/pi-coding-agent

3. Sign in without a browser

Start pi in your project folder and run /login. Choose a provider and either sign in with a subscription or store an API key. A server has no local browser, and Pi's providers page covers exactly that: the OAuth callback may not reach the local process, so when prompted you open the sign-in URL on your own computer and paste the final redirect URL or authorization code back into Pi.

The other route is an environment variable, useful when you do not want Pi to store the key. Each provider has its own variable, for example:

export OPENROUTER_API_KEY=...   # or ANTHROPIC_API_KEY, OPENAI_API_KEY, DEEPSEEK_API_KEY ...
pi

Credentials saved by /login land in auth.json in the agent directory, which the docs tell you to keep private. A provider key in auth.json can also be a command prefixed with ! that fetches it from a secret manager when first needed. Whichever route you pick, anything Pi can read, including its environment, is visible to the commands it runs, so give it only the one credential it needs.

4. Keep sessions alive in tmux

Pi has no daemon of its own, so the terminal UI needs a terminal that survives your SSH connection. Use tmux, and enable extended keys or Shift+Enter will submit instead of adding a new line. Pi's tmux page gives the settings for tmux 3.5 or newer:

# ~/.tmux.conf
set -g extended-keys on
set -g extended-keys-format csi-u

For tmux 3.2 to 3.4 use only set -g extended-keys on. Restart the tmux server so the change applies, then:

tmux new -s pi
cd ~/project && pi
# detach with Ctrl-b d, later:
tmux attach -t pi

If the process itself is killed, pi --continue picks the last session back up from disk. Use /name to label sessions and /session to see the current session file and cost.

5. Update Pi

pi update updates Pi, pi update --extensions updates installed packages, pi update --models refreshes model catalogs and pi update --all does Pi plus packages. The command cannot update an installation provided by another package manager, such as Nix.

Driving Pi from the server: print, JSON and RPC

This is where a server beats a laptop. Pi's CLI reference lists the non-interactive interfaces, and says that when stdin or stdout is redirected, Pi uses print mode on its own.

RPC mode is the one built for automation. Every command can carry an id that its response repeats, a successful prompt response only means the prompt was accepted, and you wait for the agent_settled event to know Pi will not continue on its own. Read stdout continuously and keep stderr separate, since stdout is reserved for protocol records. Closing stdin asks Pi to shut down in order. The docs include a short Python client and an exported TypeScript RpcClient.

Unattended runs have one more setting to know. Project-local resources such as .pi/extensions and .pi/settings.json need a trust decision, and print, JSON and RPC modes cannot show the prompt. By default they skip those resources; pass --approve only for a repository you control, and --no-approve to be explicit. AGENTS.md and CLAUDE.md still load either way, so treat their contents as untrusted input.

Isolate Pi: it has no built-in sandbox

Pi's security page is blunt. It can read, change and execute files with the permissions of the account that started it, it does not ask before every tool call, and extensions and child processes run with the same permissions. Prompt injection from files or command output can steer it, and project trust does not make that safe. The page lists three ways to run Pi:

• Directly as an OS user. A dedicated account narrows what Pi can touch, but it still shares the operating system and network with other users. This is the minimum, not the goal.
• Entirely inside a container, VM or sandbox. Host files and processes you do not expose stay protected, and the docs call this usually the strongest practical option.
• Pi on the host, only its tools isolated. A narrower form of isolation: the Gondolin micro-VM extension routes read, write, edit, bash, grep, find and ls into a VM, but Pi itself and other extensions stay outside it.

On a VPS the simplest version is the plain Docker setup from Pi's containerization guide. Build an image from node:24-bookworm-slim with bash, git and ripgrep plus the npm package, then mount only the project folder:

docker run --rm -it \
  -e ANTHROPIC_API_KEY \
  -v "$PWD:/workspace" \
  -v pi-agent-home:/root/.pi/agent \
  pi-sandbox

Replace the variable with whatever your provider needs. The named volume keeps settings, credentials and sessions between runs, and the docs warn against mounting the host's ~/.pi/agentunless the container should hold your host Pi credentials. A container still sees whatever you pass in: environment variables, writable mounts and network access. Give it the folder, the one key it needs, and nothing else. The same guide also documents Docker Sandboxes and NVIDIA OpenShell for keeping real provider credentials outside the sandbox.

Then remind yourself what the box holds. If the VPS also stores production keys, deploy credentials or other projects, a prompt injection reaching Pi can reach them. Use a separate server for agent work.

Reaching it remotely and safely

Because Pi is a terminal program, remote access is SSH: key-only login, password authentication off, firewall open for SSH alone, and a Tailscale address if you want to avoid a public SSH port. Do not wrap Pi in a web terminal or publish any port for it. If you build something on RPC or the SDK, keep that process on the server and talk to it over SSH or a private network.

VPS plans and cost

Prices checked October 2026 for 2 vCPU class servers. Model usage is billed separately by your provider or subscription in every case.

The VPS rows buy you a server and nothing else: patching, firewall, Docker isolation, backups of the agent directory and the cost of your own time are yours. Compare more providers in best VPS for OpenClaw; the price table there is the same one.

The managed option: Pi in a Coding Harness

If you would rather not run a server, a Coding Harness is a hosted Linux box opened in your browser with eight coding CLIs pre-installed, Pi among them. You pick one from the workspace card, they share one persisted /workspace directory, and you sign in to Pi in the terminal with an environment key or /login. The workspace deliberately does not inject your saved provider keys under the variable names a CLI reads, so an ambient key cannot override a login you did yourself. A workspace uses one of your plan's instance slots, and your own provider bills model usage. The full walkthrough is in the hosted Pi guide.

OpenClaw Launch also hosts always-on chat agents, OpenClaw and Hermes Agent, on Telegram, Discord and WhatsApp. A coding workspace is a developer environment rather than a chatbot; see Hermes hosting and the hosting page for that side.

Frequently Asked Questions

Related Guides

• Pi Coding Agent — hosted setup guide
• Coding Harness — hosted cloud dev box
• Claude Code VPS hosting
• OpenCode VPS hosting
• Codex VPS hosting