# Running Codex CLI on a VPS: The Complete Setup

Rent a $5 box, install Codex CLI, sign in with device auth, keep it alive with tmux or systemd, and guard auth.json. The full VPS walkthrough, plus the honest hosted bridge.

*Published 2026-06-12 · https://proxyllm.ai/blog/codex-cli-on-vps*

Running Codex CLI on a VPS takes about fifteen minutes: rent a small Ubuntu box (about $5 a month at Hetzner, $6 to $12 at DigitalOcean), install Node and the CLI with `npm i -g @openai/codex`, sign in with `codex login --device-auth`, and keep work alive with tmux for sessions or systemd for scheduled jobs. The CLI is a thin client and the models run on OpenAI's side, so the smallest box on the menu is usually enough. Here is the complete walkthrough, including the part most guides skip: what the box costs you after the setup is done.

## Pick a box

| Provider     | Typical plan       | Spec              | Price (mid-2026)   |
| ------------ | ------------------ | ----------------- | ------------------ |
| Hetzner      | small cloud server | 2 vCPU / 4 GB RAM | about $5/mo        |
| DigitalOcean | Basic Droplet      | 1-2 vCPU / 2-4 GB | about $6 to $12/mo |

Prices drift; check the provider pages. Sizing logic: Codex's heavy lifting happens on OpenAI's servers, so the VPS only needs to run a Node process, git, and your repositories. CPU matters briefly during dependency installs and test runs inside the sandbox; disk matters if Codex works on large repos. Either provider's entry tier with 40 GB of disk is a comfortable start, and Ubuntu 24.04 is the assumed OS below.

## Prepare the server

```bash
ssh root@your-server-ip
adduser codex && usermod -aG sudo codex
apt update && apt upgrade -y
apt install -y git tmux curl

# Node 22 via NodeSource
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt install -y nodejs

su - codex
```

Run the jobs as a normal user, not root, so auth and config land in one predictable home directory.

## Install Codex and sign in

```bash
sudo npm i -g @openai/codex
codex --version

codex login --device-auth
# CLI prints a short code
# open chatgpt.com on any device, enter the code, approve
```

The device flow exists for exactly this machine shape, documented at developers.openai.com/codex/auth. Approval happens between you and OpenAI on whatever device has a browser; the server only receives the resulting session. Signing in with ChatGPT is what makes the server's workloads bill to your flat plan instead of metered tokens, and it is the route OpenAI's README recommends (github.com/openai/codex). Token refresh details and an SSH port-forward alternative are in [codex login without a browser](/blog/codex-login-without-browser).

One mode note before the first script: the bare `codex` command opens a terminal UI and panics without a TTY, so anything unattended must call `codex exec`. The full headless picture, TTY errors through systemd units, is in [run Codex CLI headless](/blog/codex-cli-headless-server-setup).

## Guard auth.json

The session lives in `~/.codex/auth.json`, and that file is a live credential for your ChatGPT account.

```bash
chmod 600 ~/.codex/auth.json
```

House rules: never commit it, never bake it into images or snapshots you share, and prefer running device auth on each machine over copying the file around. One account, one person, per OpenAI's terms; running the CLI on your own server with your own account is documented functionality, while a shared login wrapped around one account is the pattern that violates them.

## Keep it alive: tmux for sessions, systemd for jobs

For interactive work that should survive an SSH disconnect, tmux is the whole answer:

```bash
tmux new -s codex
codex                      # interactive session on the server
# detach: Ctrl-b d
# reattach from any later SSH login:
tmux attach -t codex
```

For unattended work, schedule `codex exec` with a systemd oneshot service plus timer, which buys you logs, retries, and `journalctl` in one move; the complete unit files are in [the headless setup guide](/blog/codex-cli-headless-server-setup). Add a daily health check so auth failures page you instead of hiding:

```bash
# /etc/cron.d/codex-health: daily auth check at 07:00
0 7 * * * codex codex exec "reply with the single word ok" >/dev/null 2>&1 || curl -fsS https://alerts.example.com/codex-down
```

The check itself spends a sliver of your plan window each day, which is exactly the kind of accounting the next section is about.

## The monthly ops bill

The box costs $5. The ownership costs more, and it arrives monthly: OS patching, noticing that the saved session needs a refresh before the 3 a.m. job fails silently, building a queue the day two apps call one box at once, deciding what happens when a plan window exhausts mid-run, and keeping logs you can actually read later. Scheduled-job patterns, failure alerting included, are in [run Codex on a schedule](/blog/run-codex-on-a-schedule).

A VPS turns Codex into infrastructure, and infrastructure is a list of promises you are now the one keeping. For a personal script and one nightly digest, that list is short and the $5 box is the right answer; we mean that without reservation.

## When the VPS stops being fun

The trade flips when other software, or other people, depend on the endpoint: every chore above stops being optional the day something downstream breaks because of it. That is the line where hosted earns its fee. [Codex Hosted](/) runs the same official, unmodified CLI in a managed container signed in with your own account via the same device flow, exposed as an OpenAI-compatible endpoint with queueing, per-lane request logs, and automatic fallback to a second account or your API key, for $129 a month flat with no inference markup.

The ops-line-by-ops-line comparison, with the breakeven math on your hours, is in [Codex Hosted vs running Codex yourself](/blog/codex-hosted-vs-running-codex-yourself). Build the server when the server is the point; rent the endpoint when the output is.
