Run Pi in the cloud, on an open source runtime you own

Three decisions the phrase hides

Running Pi in the cloud sounds like one move and turns out to be three. The first is where the four built-in tools run. Pi's tools are read, write, edit and bash. Each one acts on a filesystem, so what matters is which machine holds that filesystem. On a laptop it is the project you started Pi in. On a hosted option it is a machine that company runs, with your repository cloned into it.

The second decision is where your model credentials sit. Pi reads provider keys from the environment and takes a subscription through /login (pi.dev). A session in the cloud needs that credential at the point where a request leaves for the provider. Celesto keeps it on your machine and runs only the tools remotely. A hosted workspace that stores your sign-in keeps the credential inside the box the agent's own commands can read.

The third decision is where the diff lands. Edits made on another machine have to reach your repository. The routes differ: a sync command, a folder you open in a browser, a branch you push yourself. Teams grade hosts on the first decision and discover the third later, when they work out who reads a change before it reaches the default branch.

Kortix is the open-source AI Operating System. Its sessions answer all three. Every new session runs pi on its own isolated machine, tool calls pass the rules the agent file sets, and the work arrives as a change request a person reviews.

The Kortix path, one session at a time

1. Start a session. The sandbox clones the repo to /workspace and starts the harness, pi (session docs).
2. Work on the session's branch. The branch is named with the session_id, so the work has an address before the first edit.
3. Tool calls meet the rules. Each permission entry resolves to allow, ask or deny, and the most specific rule wins, so git status can run while rm -rf * is refused (agent docs).
4. The agent commits and opens a change request. It pushes to its session branch. A session does not put its work on the default branch by itself.
5. A person merges. Merge is default-deny for agents: a session can merge only when its agent's permissions include project.gitops.merge.

What is still there when the session ends

The branch stays in the repository with its commits. A reviewer reads the change request as a diff against the base branch, with the commits behind it. A rejected change request leaves the branch in place for the next attempt, and the session log keeps what the harness did, turn by turn.

Two records sit outside the code. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. Connector credentials are brokered server-side and never enter the machine, so a session can call a connected app without holding the key that reaches it.

When a simpler host or local Docker is the better answer

For one developer with one repository and their own keys, Pi on a laptop is the simplest setup that works. Plain Docker or the Gondolin extension adds a boundary around the process without a vendor in the middle (Pi's README). Celesto fits when you want Pi's interface and history local and only the tools elsewhere. Ellipsis fits a team that already starts work from Slack, Linear or a cron and wants a VM per session. OpenClaw Launch's hosted workspace fits a developer who wants a box with several coding agents installed and a browser terminal. Kortix is the one here that also holds the permission rules and the review, and you can run it on your own network if the work cannot leave it.

Before any of that, Pi has to be installed and driven once by hand. The Pi coding agent guide covers the install and the first session, and what a Pi harness is explains the loop.