Claude Code on a VPS

The same Claude Code you run locally, on a small Linux server that never sleeps. You reach it over SSH from a laptop or a phone, the session survives your connection dropping, and a job you start on the train is still running when you get off.

You need a Claude subscription that includes Claude Code — Pro, Max, Team or Enterprise — or an Anthropic Console account billed per token. The free Claude.ai plan does not include it, which is the first thing to check rather than the last.

You will read that Claude Code barely needs anything because the model runs on Anthropic's servers. The first half is true and the conclusion is wrong. Anthropic's own requirements ask for 4 GB of RAM and Ubuntu 20.04+, Debian 10+ or equivalent — and that is before your actual work.

The model does the thinking remotely; the box does everything else. Cloning the repository, installing dependencies, running the test suite, building the site — all of it happens on that server. Size the machine for your build, not for the agent. A 1 GB box will install fine and then die halfway through something, at the least convenient moment.

In practice: 2 vCPU and 4 GB is a comfortable floor at roughly $5–10 a month from any of the usual providers, and 8 GB if your project is heavy or you want two agents on one box. Disk fills faster than you expect — 40 GB or more.

Do not do any of this as root. Make a user, log in as that user, and run the native installer:

curl -fsSL https://claude.ai/install.sh | bash
claude --version

That drops a binary in ~/.local/bin and keeps itself updated in the background. If your shell cannot find claude afterwards, that directory is not on your PATH yet — open a new shell.

There is an npm package too (npm install -g @anthropic-ai/claude-code), which installs the same binary but wants Node 22 or later. On a fresh server the installer above is one less thing to maintain. There are signed apt, dnf and apk repositories as well if you would rather your package manager owned it — those do not auto-update.

Then confirm the install is actually healthy rather than merely present:

claude doctor

Run claude on your laptop and it opens a browser to log you in. On a server there is no browser to open, and this is where most people get stuck. Three ways through, and which one you want depends on what you are paying for.

If you have a subscription (Pro or Max): generate a long-lived token on the machine that does have a browser — your laptop — and carry it over. It lasts about a year.

# On your laptop, where a browser can open:
claude setup-token

# On the server, in a file only you can read:
export CLAUDE_CODE_OAUTH_TOKEN=...

If you have Console access: set ANTHROPIC_API_KEY instead and skip the login entirely. Simpler, and you are billed per token rather than per month — for an agent left running unattended, that is a meter you should actually watch.

Or forward the callback. Anthropic's login can hand you a URL to paste into any browser, and you can SSH-forward the callback port so the redirect lands back on the server. It works. It is also the option you will have to rediscover in a year when the token expires.

Whichever you pick, that value is a live credential to your account. Put it in a file with chmod 600, never in the repository, and remember that anything with a shell on this box can read it.

Start work inside tmux, so it survives your SSH connection dropping — which it will, on a train:

tmux new -s work
claude
# Ctrl-b then d detaches. Come back with:
tmux attach -t work

tmux does not survive a reboot, and your provider will reboot the box eventually. A user-level systemd unit brings the session back:

# ~/.config/systemd/user/agent.service
[Unit]
Description=Long-running Claude Code session
After=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=%h/project
EnvironmentFile=%h/.config/claude/env
ExecStart=/usr/bin/tmux new-session -d -s work
ExecStop=/usr/bin/tmux kill-session -t work

[Install]
WantedBy=default.target

systemctl --user enable --now agent
sudo loginctl enable-linger $USER   # keeps it running when you log out

Be clear about what that buys you: the session comes back after a reboot, empty. It does not remember what you were in the middle of. Picking the work back up stays manual, and no amount of unit file fixes that.

One gotcha that costs an evening: a token exported in ~/.bashrc is not there for systemd, and often not for a fresh tmux pane either. Put it in the unit's EnvironmentFile as above, or in ~/.profile, and check with systemctl --user show-environment rather than assuming.

The basics, quickly: SSH keys only and password login off, a firewall that allows 22 and nothing else you did not choose, unattended security updates on, and the agent running as an ordinary user rather than root.

The part worth actually thinking about: this box holds a credential to your Anthropic account, probably a deploy key or a Git token, and it runs an agent that executes commands. That is a real blast radius. Put nothing on it you would mind losing, give it repository access scoped to the repositories it needs, and keep production credentials somewhere else.

The server is $5–10 a month and everyone quotes that number. It is not the price.

The model access is on top — your Claude subscription, or Console tokens metered by the job. And the third line is your attention, which is the one nobody puts in the comparison table. Here is what it gets spent on:

The reboot. A kernel update restarts the box and every session with it, and unless you set up the unit above, nothing comes back.

The full disk. Node modules, build artefacts, logs, an npm cache nobody cleans. The failure looks like the agent going strange rather than like a disk error.

The expired token. In about a year, and you will have forgotten how you made the last one.

The silent finish. The job completed at 2am and nothing told you, so it sat there until you next thought to SSH in and look. A server keeps the work alive; it does not bring you the result.

The waiting agent. If it stopped to ask permission, it is still stopped. Moving to a server fixes the sleeping laptop and not this — see the two halves of the problem.

Yes if you want a shell on the box. If your instinct on reading the systemd unit was to improve it, this is your setup and you will be happy with it — you get total control, any tooling you like, and a bill that does not surprise you.

Probably not if what you wanted was the finished work. Everything above is administration you are doing so that an agent can work, and none of it is the thing you set out to build. Our comparison of the four ways lays out the alternatives fairly, including the ones that are not us.