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

> Running Pi in the cloud means moving the tools somewhere, and that is the first of three decisions. Where your model credentials stay and where the diff lands decide the rest. Kortix is the open-source AI Operating System, and it answers all three.

URL: https://picodingagentguide.com/run-pi-in-the-cloud

Three decisions, one runtime

**The open-source AI Operating System**

`agents/<name>.md`

```yaml
permission:
  edit: allow
  bash:
    "*": ask
    "rm -rf *": deny
  webfetch: ask
```

Source: https://kortix.com/docs/project/agents

Per-resource permissions for people and agents. Roles, groups, and an audit trail.

[Try Kortix](https://kortix.com) · [Read the comparison](https://picodingagentguide.com/#compare)

One isolated machine per session · Your keys or your ChatGPT plan · A change request a person merges

## Where the tools run, where the keys stay, where the diff lands

Each cell is what that option's own page states, read on 28 October 2026. Where a page is silent, the cell says so rather than guessing.

| | Kortix (recommended) | Celesto | Ellipsis | OpenClaw Launch | Your own build |
| --- | --- | --- | --- | --- | --- |
| Open source | Yes | Yes, open-source core | Not stated on its page | Not stated on its page | Yes |
| Where the tools run | Its own isolated machine, one per session | Read, write, edit and bash on an isolated Celesto computer | Its own cloud VM, repo cloned, dependencies installed | A hosted workspace, your code in /workspace | Docker runs Pi locally; Gondolin keeps auth on the host |
| Where model credentials stay | Spent server-side: model keys and the ChatGPT sign-in never reach the sandbox | On your machine; never enter the Celesto computer | Not stated on its page | In the workspace home directory; a saved key is opt-in per request | In the process environment, on your own machine |
| What starts a session | On demand, on a cron, or on a webhook | You run `pi --celesto` in a project | API, webhook, a Slack or Linear mention, cron | A terminal in the workspace, or its API | Whatever you script: a shell, a CI job, a call |
| How work comes back | A change request a person reviews and merges | `/celesto sync` copies changes back, conflicts preserved | Not stated on its page | Code persists in `/workspace`, read in a browser terminal | Wherever you wrote it; no review step of its own |
| Where it can run | Kortix Cloud, your VPC, or your own on-prem network | Celesto cloud; the microVM behind its sandboxes can run on your own infrastructure | Its own cloud; no self-host stated | Hosted workspaces; self-host not stated | Your machine, or your own Cloudflare account |
| What its page says about price | Free $0, 500 credits a month; Credits from $50 a month | Free plan, no credit card required | Not stated on its page | Not stated on the guide | Your machine and model bills |

Plans and pages read on 28 October 2026. Kortix prices come from its pricing page, and the free plan takes your own keys or your ChatGPT subscription.

## 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](https://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.

## Two blocks from the Kortix docs

The permission rules a session runs under, and what the audit log keeps.

### Permission

`agents/<name>.md`

```yaml
permission:
  edit: allow
  bash:
    "*": ask
    "rm -rf *": deny
  webfetch: ask
```

Source: https://kortix.com/docs/project/agents

### Audit

`audit log`

```
Every action is recorded.
Reading, exporting and streaming the audit log depend on the plan.
```

Source: https://kortix.com/docs

## 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](https://kortix.com/docs/work/sessions)).
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](https://kortix.com/docs/project/agents)).
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](https://github.com/earendil-works/pi)). 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](https://kortix.com/docs) 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](/pi-harness) explains the loop.

## Questions people ask before they pick a host

### How to launch pi coding agent?

Install Pi from pi.dev, then run `pi` in the project and use `/login` for a subscription or an API key. In the cloud, Celesto runs the tools remotely, Ellipsis runs each session in a cloud VM, and Kortix starts pi in a session on its own isolated machine.

### Where do my credentials stay when Pi runs in the cloud?

In Kortix they stay outside the sandbox: model provider keys belong on the Models page or with `kortix providers set`, and Kortix spends those keys server-side, while the ChatGPT subscription sign-in (`CODEX_AUTH_JSON`) never reaches a sandbox either. A session's own commands never hold a model credential. Celesto keeps Pi, the conversation and the model credentials on your machine and runs read, write, edit and bash in its cloud computer.

### What comes back to my repository when a cloud session ends?

A branch. In Kortix the agent commits to a branch named with the session id and opens a change request a person reviews and merges; a rejected change request leaves the branch for the next attempt. Celesto copies changes back with `/celesto sync`, and a browser workspace leaves the code in `/workspace`.

## Put the rules and the review around the run

Every new session in Kortix runs pi on its own isolated machine and lands the work as a change request.

[Try Kortix](https://kortix.com) · [What the plan costs](https://picodingagentguide.com/pi-coding-agent-pricing)