---
title: "Run magpie on a server"
description: "Run yetone's magpie model gateway in Docker on an always-on exe.dev VM: one private gateway with failover for the agents on all your machines."
url: https://exe.dev/deploy/magpie
category: "AI agents"
updated: 2026-11-13
---

# Run magpie on a server

One model gateway, with failover, for every agent on every machine.

- **Software:** magpie (https://usemagpie.ai)
- **Source:** https://github.com/yetone/magpie
- **License:** MIT
- **Time:** 10 minutes
- **Example VM name:** `my-magpie` (yours will differ; on the VM, `hostname` prints it)
- **Machine-readable:** https://exe.dev/deploy/magpie/manifest.json

## What you get

- magpie running in Docker Compose on ports 3425 and 3430, bound to the VM's loopback and back after a reboot
- A web key in `~/magpie/.env`, readable only by you, and magpie's settings on the VM's disk in `~/magpie/config`
- exe.dev's LLM integration added to magpie as two providers, with no API key, and a routing group `group/open-models` that fails over from Kimi K3 to GLM-5.3 to DeepSeek V4.1 Flash
- A gateway key for this VM in `~/magpie/this-vm.key`, and Claude Code on the VM answering through `group/open-models`
- The web UI at `https://<vm>.exe.xyz:3430/`, private to you

Running on the VM:

- **magpie**: `magpie web` from ghcr.io/yetone/magpie:stable, in Docker Compose, port 3425, data in `~/magpie/config (providers, gateway keys, routing groups, usage)`
- **magpie web UI**: the same container; it answers the gateway's /v1 routes too, port 3430
- **exe.dev LLM integration**: magpie's first upstream, for Claude, GPT, Kimi, GLM and DeepSeek with no API key

How it is reached:

- https://my-magpie.exe.xyz:3430/ (private): magpie's web UI, behind exe.dev login and magpie's own web key
- https://my-magpie.exe.xyz:3425/ (private): the gateway for your laptop and CI, with an exe.dev VM token and a magpie gateway key
- https://magpie.int.exe.xyz/ (private): the gateway from your other exe.dev VMs, through a VM-to-VM integration
- http://127.0.0.1:3425/ (private): the gateway for agents on the VM itself

## Deploy with Shelley

Open https://exe.dev/new?prompt=Set%20up%20magpie%20on%20this%20VM%20by%20following%20the%20exe.dev%20recipe%20at%20https%3A%2F%2Fexe.dev%2Fdeploy%2Fmagpie.md%20from%20top%20to%20bottom.%0A%0AThe%20recipe%27s%20example%20VM%20name%20is%20my-magpie.%20This%20VM%27s%20name%20is%20the%20output%20of%20%60hostname%60%3A%20use%20it%20wherever%20the%20recipe%20writes%20my-magpie.%20Skip%20the%20step%20that%20creates%20the%20VM%3B%20you%20are%20on%20it.%0A%0AYou%20are%20done%20when%20all%20of%20these%20are%20true.%20Check%20each%20one%20yourself%3A%0A-%20magpie%20running%20in%20Docker%20Compose%20on%20ports%203425%20and%203430%2C%20bound%20to%20the%20VM%27s%20loopback%20and%20back%20after%20a%20reboot%0A-%20A%20web%20key%20in%20%60~%2Fmagpie%2F.env%60%2C%20readable%20only%20by%20you%2C%20and%20magpie%27s%20settings%20on%20the%20VM%27s%20disk%20in%20%60~%2Fmagpie%2Fconfig%60%0A-%20exe.dev%27s%20LLM%20integration%20added%20to%20magpie%20as%20two%20providers%2C%20with%20no%20API%20key%2C%20and%20a%20routing%20group%20%60group%2Fopen-models%60%20that%20fails%20over%20from%20Kimi%20K3%20to%20GLM-5.3%20to%20DeepSeek%20V4.1%20Flash%0A-%20A%20gateway%20key%20for%20this%20VM%20in%20%60~%2Fmagpie%2Fthis-vm.key%60%2C%20and%20Claude%20Code%20on%20the%20VM%20answering%20through%20%60group%2Fopen-models%60%0A-%20The%20web%20UI%20at%20%60https%3A%2F%2F%3Cvm%3E.exe.xyz%3A3430%2F%60%2C%20private%20to%20you%0A%0ARun%20the%20VM-side%20commands%20in%20%22Install%20by%20hand%22%20only%2C%20skipping%20VM%0Acreation.%20Never%20run%20share%20set-public%20or%20share%20port%2C%20never%20publish%203425%0Aor%203430%20beyond%20127.0.0.1%2C%20and%20never%20sign%20magpie%20in%20to%20a%20subscription%0A%28%60magpie%20accounts%20add%60%2C%20Claude%2C%20ChatGPT%20and%20the%20like%29.%20Verify%20that%0A%60docker%20compose%20ps%60%20shows%20the%20container%20healthy%2C%20that%0A%60curl%20-s%20-o%20%2Fdev%2Fnull%20-w%20%27%25%7Bhttp_code%7D%27%20http%3A%2F%2F127.0.0.1%3A3425%2Fv1%2Fmodels%60%0Aprints%20401%2C%20and%20that%20the%20Claude%20Code%20check%20prints%20OK.%20Never%20print%20the%0Agateway%20key%20in%20your%20messages.%20Finish%20by%20giving%20the%20owner%20the%20web%20UI%0Alink%20from%20%22Open%20the%20web%20UI%22%20with%20this%20VM%27s%20name%20and%20its%20%3Fk%3D%20key%20%28this%0Aconversation%20is%20private%20to%20them%29%2C%20and%20point%20them%20to%20%22Use%20it%20from%20your%0Alaptop%22%20and%20%22Use%20it%20from%20your%20other%20VMs%22%2C%20which%20they%20set%20up%20on%20their%0Aown%20computer.%0A%0AFinish%20with%20the%20URLs%20I%20should%20open.%0A to create a VM whose agent, Shelley, follows this recipe. From a terminal:

```sh
curl -fsSL https://exe.dev/deploy/magpie/prompt.txt | ssh exe.dev new --prompt=/dev/stdin
```

Or follow the steps below by hand.

[magpie](https://usemagpie.ai) is yetone's model switcher and gateway for
coding agents: Claude Code on Kimi, Codex on DeepSeek, Gemini CLI on GLM.
One gateway speaks the OpenAI, Anthropic and Gemini APIs, translates
between them, and moves to the next model or provider when one runs out of
quota or goes down. On a laptop it serves that laptop. Run it in
[Docker on an exe.dev VM](https://usemagpie.ai/docs/docker) instead and
it's one gateway that's always on, for your laptop, your other VMs and CI,
with one place to keep providers, routing groups and usage.

The gateway stays private: exe.dev's [HTTPS proxy](/docs/proxy) lets in
only you, VMs you connect, and clients holding an exe.dev token, and magpie
asks every one of them for its own gateway key as well. Its first provider
is exe.dev's [LLM integration](/docs/integrations-llm), so it works the
moment it's installed, with no API key on the VM.

> [!WARNING]
> magpie can also sign in to Claude, ChatGPT and other subscriptions and
> spread requests over several accounts. Sharing a subscription through a
> gateway, or pooling accounts, may break the provider's terms. This page
> uses API keys and exe.dev's gateway; check your providers' terms before
> adding anything else.

## Install

Deploy starts magpie, connects it to exe.dev's models, and checks that
Claude Code answers through it. To do it yourself:

<details id="create-the-vm" data-manual-setup class="dp-details">
<summary>Install by hand</summary>

On your computer, create a VM and connect. Pick any free name:

```bash
ssh exe.dev new --name=my-magpie
ssh my-magpie.exe.xyz
```

### Start magpie

On the VM, make Docker start on boot, then make a folder for magpie's
settings that the container's user (uid 65532) can write. The web key and
the gateway's address go in `.env`, readable only by you:

```bash
sudo systemctl enable --now docker.service
mkdir -p ~/magpie/config && cd ~/magpie
sudo chown 65532:65532 config
install -m 600 /dev/null .env
cat > .env <<EOF
MAGPIE_WEB_KEY=$(openssl rand -hex 16)
MAGPIE_PUBLIC_URL=https://$(hostname).exe.xyz:3425
EOF
```

Both ports listen on the VM's loopback only. exe.dev's proxy still reaches
them, and nothing else can:

```bash
cat > compose.yaml <<'EOF'
services:
  magpie:
    image: ghcr.io/yetone/magpie:stable
    restart: unless-stopped
    ports:
      - "127.0.0.1:3425:3425"   # the gateway
      - "127.0.0.1:3430:3430"   # the web UI
    env_file: .env
    volumes:
      - ./config:/config
    command: [web, --addr, 0.0.0.0:3430, --no-open]
EOF
docker compose up -d
sleep 10
docker compose ps
```

The container shows as `healthy`. `stable` is magpie's weekly channel,
which suits a server: magpie releases several times a day, and `latest`
follows every release.

### Add a `magpie` command

magpie's CLI is in the container. A small wrapper runs it from the VM's
shell, and from your computer over `ssh`:

```bash
sudo tee /usr/local/bin/magpie >/dev/null <<'EOF'
#!/bin/sh
# magpie's CLI, run in its container
if [ -t 0 ]; then t=; else t=-T; fi
exec docker compose -f "$HOME/magpie/compose.yaml" exec $t magpie magpie "$@"
EOF
sudo chmod +x /usr/local/bin/magpie
magpie --version
```

It prints magpie's version, such as `magpie v0.1.3078`.

### Connect exe.dev's models

Add exe.dev's LLM integration as two providers: one for Claude over the
Anthropic API, one for everything else over the OpenAI API. The key is a
placeholder; exe.dev adds the real credentials outside the VM:

```bash
magpie provider add exe-claude anthropic=https://llm.int.exe.xyz key=exe-gateway \
  models=claude-opus-5-5,claude-sonnet-5-5,claude-haiku-5-5
magpie provider add exe url=https://llm.int.exe.xyz/v1 key=exe-gateway \
  models=gpt-6-luna,fireworks/kimi-k3,fireworks/glm-5p3,fireworks/deepseek-v4p1-flash
magpie provider test exe-claude
magpie provider test exe
```

Both tests print a `✓` with a model name. `models=` picks what agents
see; `curl -s https://llm.int.exe.xyz/v1/models` lists the rest.

Then make a routing group: agents ask for `group/open-models`, and magpie
uses Kimi K3 until it can't answer, then GLM-5.3, then DeepSeek:

```bash
magpie group add "Open models" routing=order \
  models=exe/fireworks/kimi-k3,exe/fireworks/glm-5p3,exe/fireworks/deepseek-v4p1-flash
```

### Make a key and check

Every caller outside the container needs a gateway key, the VM's own
agents included. Make one for this VM and keep it in a file only you can
read:

```bash
install -m 600 /dev/null ~/magpie/this-vm.key
magpie gateway-key add this-vm | grep -o 'sk-magpie-[A-Za-z0-9_-]*' > ~/magpie/this-vm.key
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3425/v1/models
curl -s http://127.0.0.1:3425/v1/models -H "Authorization: Bearer $(cat ~/magpie/this-vm.key)" | jq -r '.data[].id'
```

The first `curl` prints `401`: no key, no answer. The second lists
`group/open-models` and the seven models. Now have Claude Code, which comes
with the VM, answer through the group:

```bash
ANTHROPIC_BASE_URL=http://127.0.0.1:3425 ANTHROPIC_API_KEY=$(cat ~/magpie/this-vm.key) \
  claude -p --model group/open-models "Reply with exactly: OK"
```

It prints `OK`, after a note that Claude Code doesn't know the model's
context window; that's expected for a gateway's model names.

</details>

## Open the web UI

magpie's web UI is where you add providers, make routing groups and keys,
and watch every request. On your computer, print its address with its key:

```bash
ssh my-magpie.exe.xyz 'echo "https://$(hostname).exe.xyz:3430/?k=$(grep MAGPIE_WEB_KEY ~/magpie/.env | cut -d= -f2)"'
```

Open it and log in to exe.dev. magpie trades the key for a cookie that
lasts 400 days, so later visits need only `https://my-magpie.exe.xyz:3430/`.
Port 3430 is private: exe.dev's login decides who reaches it, and the web
key keeps out anyone you've shared the VM with but not given the key.
Anyone with both can see and change your providers and keys, so treat the
link like a password.

The UI is in gateway mode: **Providers**, **Routing**, **Gateway** (its
keys), **Usage** and **Sessions**. There's no **Agents** page, since the
agents run on your other machines. Send a few requests through
`group/open-models` and open **Routing** to see which member answered each
one and why.

<figure>
<img src="https://exe.dev/deploy/magpie/routing.png" alt="magpie's Routing page: Claude Code asked for group/open-models, and exe's fireworks/kimi-k3 answered, with GLM-5.3 and DeepSeek V4.1 Flash next in order" width="1280" height="800" loading="lazy">
<figcaption>Claude Code on the VM asked for <code>group/open-models</code>; Kimi K3 answered, and the next two members wait their turn.</figcaption>
</figure>

## Use it from this VM

Agents on the VM call `http://127.0.0.1:3425` with the key in
`~/magpie/this-vm.key`. For Claude Code, add to `~/.bashrc`:

```bash
export ANTHROPIC_BASE_URL=http://127.0.0.1:3425
export ANTHROPIC_API_KEY=$(cat ~/magpie/this-vm.key)
```

Then `claude --model group/open-models`, or any model `magpie models`
lists, such as `exe/fireworks/glm-5p3`. Codex uses the OpenAI side,
with Claude models too:

```bash
MAGPIE_API_KEY=$(cat ~/magpie/this-vm.key) codex exec --skip-git-repo-check \
  -m exe-claude/claude-haiku-5-5 -c model_provider=magpie \
  -c 'model_providers.magpie.name="magpie"' \
  -c 'model_providers.magpie.base_url="http://127.0.0.1:3425/v1"' \
  -c 'model_providers.magpie.env_key="MAGPIE_API_KEY"' \
  -c 'model_providers.magpie.wire_api="responses"' \
  "Reply with exactly: OK"
```

Anything else that takes a base URL works the same way:
`http://127.0.0.1:3425/v1` for an OpenAI client, `http://127.0.0.1:3425`
for an Anthropic or Gemini one, and a gateway key as its API key.

## Use it from your laptop

From outside exe.dev, a request needs two things: an exe.dev **VM token**,
which gets it through the HTTPS proxy, and a magpie **gateway key**, which
magpie checks. On your computer, make a token that only opens this VM
(`--exp` sets when it stops working):

```bash
ssh exe.dev ssh-key generate-api-key --vm=my-magpie --label=magpie-laptop --exp=90d
```

Then make the laptop its own gateway key, so you can limit it and turn it
off on its own. `gateway-key list` shows its ID:

```bash
ssh my-magpie.exe.xyz magpie gateway-key add laptop
ssh my-magpie.exe.xyz magpie gateway-key list
```

Optionally hold the key to a daily budget and some models (put its ID in
place of `KEY_ID`):

```bash
ssh my-magpie.exe.xyz magpie gateway-key limit KEY_ID day --cost 5
ssh my-magpie.exe.xyz magpie gateway-key models KEY_ID "'exe/*'" group/open-models
```

A request for any other model then gets a 403 that names the models the
key may use. The exe.dev token goes in the `X-Exedev-Authorization` header,
which exe.dev checks and strips ([HTTPS tokens for VMs](/docs/https-tokens-for-vms)).
For Claude Code on your laptop:

```bash
export ANTHROPIC_BASE_URL=https://my-magpie.exe.xyz:3425
export ANTHROPIC_API_KEY=sk-magpie-key-paste-yours-here
export ANTHROPIC_CUSTOM_HEADERS="X-Exedev-Authorization: Bearer exe1.paste-yours-here"
claude --model group/open-models
```

For Codex, add a provider to `~/.codex/config.toml`, then run
`MAGPIE_API_KEY=sk-magpie-key-paste-yours-here codex -c model_provider=magpie -m group/open-models`:

```toml
[model_providers.magpie]
name = "magpie"
base_url = "https://my-magpie.exe.xyz:3425/v1"
env_key = "MAGPIE_API_KEY"
wire_api = "responses"
supports_websockets = false
http_headers = { "X-Exedev-Authorization" = "Bearer exe1.paste-yours-here" }
```

We ran both from another machine with these settings: each answered
through `group/open-models`. With the token but no gateway key, magpie
answers 401; with the key but no token, exe.dev sends a login redirect.

CI jobs work the same way, with the token and a gateway key in the CI's
secrets. magpie can also hand out
[short-lived keys](https://usemagpie.ai/docs/remote#short-lived-keys) that
expire by themselves (`magpie gateway-key issue --ttl 1h --name ci`), so a
job never holds a long-lived one.

## Use it from your other VMs

Your other exe.dev VMs don't need the exe.dev token: a
[VM-to-VM integration](/docs/integrations-vm-to-vm) adds one at the
network edge, where the calling VM can't read it. On your computer, attach
one to the VMs that should use magpie (here `my-agent-vm`):

```bash
ssh exe.dev integrations add http-proxy --name magpie \
  --target https://my-magpie.exe.xyz:3425/ --peer --attach vm:my-agent-vm
```

Make that VM a gateway key of its own, as for the laptop, then on it:

```bash
export ANTHROPIC_BASE_URL=https://magpie.int.exe.xyz
export ANTHROPIC_API_KEY=sk-magpie-key-paste-yours-here
claude --model group/open-models
```

magpie's **Usage** page counts each VM's requests under its key's name.
We ran this from a second VM: Claude Code answered through
`group/open-models`, and a request without a gateway key got a 401.

## Add providers

Add the providers you have API keys for in the web UI (**Providers → Add
provider**, then a preset and a key), or with the `magpie` command on the
VM:

```bash
magpie presets                       # every vendor magpie knows
magpie provider add deepseek sk-...  # a preset needs only the key
magpie group add "Daily" routing=order models=deepseek/deepseek-v4-pro,group/open-models
```

A group can hold other groups, so `Daily` uses your DeepSeek key first and
falls back to exe.dev's models when DeepSeek fails or runs out. We checked
failover with a provider that couldn't be reached: the request was answered
by the next member, and magpie's usage log marked it as answered on a retry.

A key you add to magpie is stored on the VM, in `~/magpie/config`. To keep
it off the VM:

- **Anthropic, OpenAI and Fireworks**: put your key in exe.dev's
  [LLM integration](/docs/integrations-llm) ("API Key" instead of "exe.dev
  LLM gateway"). magpie's `exe` and `exe-claude` providers then use your
  key, with nothing to change on the VM.
- **Other vendors**: put the key in an
  [HTTP proxy integration](/docs/integrations-http-proxy) and give magpie
  the integration's address with a placeholder key. For DeepSeek, on your
  computer:

  ```bash
  printf '%s' "$DEEPSEEK_API_KEY" | ssh exe.dev integrations add http-proxy \
    --name deepseek --target https://api.deepseek.com --bearer=- --attach vm:my-magpie
  ```

  Then on the VM, a custom provider that knows DeepSeek's models
  (`catalog=deepseek`) but sends nothing to `api.deepseek.com` itself:

  ```bash
  magpie provider add "DeepSeek" id=deepseek url=https://deepseek.int.exe.xyz/v1 \
    anthropic=https://deepseek.int.exe.xyz/anthropic key=not-a-secret catalog=deepseek
  ```

  Give every URL this way: a preset given only `url=` still sends its
  Anthropic and Responses requests to the vendor. We checked which
  addresses and headers magpie uses, but haven't run this with a real
  DeepSeek key.

## Back up and restore

Everything magpie keeps is in `~/magpie`: providers and their keys,
gateway keys, routing groups, usage, and the web key in `.env`. Archive it
on the VM, and keep the archive private:

```bash
mkdir -p ~/backups
cd ~/magpie && docker compose stop
sudo tar -C ~ -czf ~/backups/magpie-$(date +%F).tar.gz magpie
sudo chown $USER: ~/backups/magpie-*.tar.gz && chmod 600 ~/backups/magpie-*.tar.gz
docker compose start
```

To restore one, replace `2026-11-13` with the archive's date:

```bash
cd ~/magpie && docker compose down
sudo rm -rf ~/magpie
sudo tar -C ~ -xzf ~/backups/magpie-2026-11-13.tar.gz
cd ~/magpie && docker compose up -d
```

Your providers, groups and gateway keys come back as they were, so clients
keep working. For a copy of the whole VM, run
`ssh exe.dev cp my-magpie my-magpie-backup` on your computer.

## Update

magpie in Docker is updated by pulling a new image; settings stay in
`~/magpie/config`:

```bash
cd ~/magpie && docker compose pull && docker compose up -d
magpie --version
```

The `stable` tag moves about once a week. For every release, change it to
`latest` in `compose.yaml`; to stay on one version, use its number
(`ghcr.io/yetone/magpie:0.1.3078`). See the
[releases](https://github.com/yetone/magpie/releases).

## Troubleshooting

- **`401` from the gateway.** The request has no enabled gateway key, or
  sent it in the wrong place. Send it as `Authorization: Bearer` or
  `x-api-key`; the web UI's cookie and the web key aren't gateway keys.
- **A login page or `307` instead of an answer.** The request reached
  exe.dev's proxy without a VM token. Check the `X-Exedev-Authorization:
  Bearer exe1...` header, and that the token was made with
  `--vm=my-magpie` and hasn't expired.
- **`403` for a model.** That key is held to some models:
  `magpie gateway-key list` shows which, and
  `magpie gateway-key models <id> all` lifts it.
- **The web UI says 401.** Open it once with `?k=` and the web key, as in
  "Open the web UI"; a new browser needs it again.
- **It's gone after a reboot.** `systemctl is-enabled docker.service`
  should say `enabled`; run `sudo systemctl enable --now docker.service`
  if not.
- **`permission denied` under `/config` in the log.** The folder isn't
  the container's: `sudo chown -R 65532:65532 ~/magpie/config`, then
  `docker compose restart`.
- **A provider fails.** `magpie provider test <id>` sends one small request
  per API and prints the vendor's error.

For everything else, see magpie's [Docker guide](https://usemagpie.ai/docs/docker)
and [reference](https://github.com/yetone/magpie/blob/main/docs/reference.md),
or ask on its [Discord](https://discord.gg/vGSnD3ZKQF).

## Frequently asked questions

### magpie or exe.dev's own LLM gateway?

Often both, as on this page. exe.dev's [LLM integration](/docs/integrations-llm) is on every VM already: Claude, GPT, Grok and Fireworks' open models, with no key on the VM, but only for your exe.dev VMs. magpie adds what it doesn't do: vendors exe.dev doesn't carry (Moonshot's, Zhipu's and DeepSeek's own APIs, OpenRouter, a local Ollama), routing groups that fail over between models and providers, API translation (Claude Code on Kimi, Codex on Claude), one key per client with its own budget and models, and one usage page for all of it, reachable from your laptop and CI. If one agent on one VM is all you have, skip magpie.

### Can magpie pool my Claude or ChatGPT subscriptions?

It can sign in to subscriptions and fail over between several accounts, but this page doesn't, on purpose. A subscription is usually for one person in the vendor's own apps; serving it from a shared gateway, or pooling accounts to get around limits, may break the provider's terms. Use API keys, exe.dev's gateway, or a plan the provider lets you use this way, and check your providers' terms.

### Can I make the gateway public instead?

You could point the VM's public port at 3425 with `share port` and `share set-public`: we checked that magpie then refuses every request without a gateway key (401). But a leaked key is then usable from anywhere, magpie's allowed-addresses list can't help behind a proxy, and magpie's own docs say not to open the gateway to the internet. exe.dev's VM tokens and VM-to-VM integrations give you a second lock for free, so keep it private.

### Can I use Tailscale instead?

Yes. Join the VM to your tailnet with the [Tailscale integration](/docs/integrations-tailscale-wif), change the gateway's port line in `compose.yaml` to the VM's Tailscale address (`"100.x.y.z:3425:3425"`), and set `MAGPIE_ALLOW_IPS=100.64.0.0/10` in `.env`. Clients then call `http://100.x.y.z:3425` with a gateway key and no exe.dev token. We tested the exe.dev routes on this page, not Tailscale.

### How much does it cost?

magpie is free and MIT-licensed, and uses about 30 MB of memory, so it fits on any VM in your exe.dev plan. Models through exe.dev's gateway are billed to your exe.dev account (see the [models and prices](/llm-gateway-models)); providers you add with your own keys bill you directly. magpie's Usage page shows the cost of every request by agent, model and gateway key.

### Something's not working. Where do I look?

On the VM, `cd ~/magpie && docker compose logs --tail 80` shows magpie's log, and the web UI's **Routing** page shows how each request was routed and which member answered. [Troubleshooting](#troubleshooting) covers the usual problems.


## Related

- [Run Claude Code on a remote server](https://exe.dev/deploy/claude-code.md): A computer for Claude. A breather for your laptop.
- [Run Codex on a remote server](https://exe.dev/deploy/codex.md): A computer for Codex. An early night for your laptop.
- [Run Kimi Code CLI on a remote server](https://exe.dev/deploy/kimi-code.md): Moonshot's coding agent, with a Linux box that never sleeps.
- [Run DeepSeek Harness on a remote server](https://exe.dev/deploy/deepseek-harness.md): DeepSeek's agent in a browser tab, on a computer that never sleeps.
- [Give agents API access without giving them the keys](https://exe.dev/deploy/agent-secrets.md): Your agents call your APIs. The keys stay with exe.dev, outside the VM.
- [Run OpenCode on a remote server](https://exe.dev/deploy/opencode.md): Every model, one VM, and an agent that works while your laptop sleeps.