Early access: your sandbox is free, with $5 of AQ Composer credits every month. Your own subscriptions stay unmetered. Start free

aq.dev / guides / run-claude-code-on-a-cloud-vm

How to Run Claude Code on a Cloud VM

To run Claude Code on a cloud VM: provision a small Linux server (Ubuntu 22.04 or 24.04 with at least 4 GB of RAM), install the CLI with Anthropic's one-line installer (curl -fsSL https://claude.ai/install.sh | bash), run claude and sign in once over SSH using the paste-code login flow, then start every session inside tmux so it survives disconnects. The whole setup takes about fifteen minutes, and the payoff is an agent that keeps working after your laptop lid closes, that you can reattach to from any device, and that holds its credentials on a machine you control. This guide walks through each step, hardening included, with every Claude Code detail checked against Anthropic's documentation as of October 2026.

Why put Claude Code on a server at all

On a laptop, Claude Code dies with your terminal: close the lid mid-task and the session is gone. On a VM the process runs on hardware that never sleeps, so a long refactor keeps going through your commute, and you can check on it from a different machine (or your phone with an SSH client) by simply reattaching. Two quieter benefits: the blast radius of an agent running with relaxed permission prompts is confined to a disposable box instead of the machine that holds your email and password manager, and the VM gives agent credentials and repository clones a stable home independent of any laptop.

Step 1: Provision the VM

Anthropic's stated requirements are modest and unchanged as of October 2026: Ubuntu 20.04+, Debian 10+, or Alpine 3.19+, on x64 or ARM64, with 4 GB or more of RAM. In practice, size for what runs next to the agent. If the repository has a heavy npm or cargo build, or you keep a dev server running while the agent works, 8 GB is the comfortable floor; 2 vCPUs and 4 GB is fine for the agent plus a lightweight toolchain. ARM instances are usually cheaper and work fine, since Claude Code ships ARM64 builds.

Pick Ubuntu 24.04 LTS unless you have a reason not to: every tool in this guide has first-class packages there. On a 4 GB machine, add swap so a hungry build gets slow instead of killed:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Any provider works. As of October 2026, a 2 vCPU, 4 GB basic droplet at DigitalOcean runs $24 per month, and the AWS Lightsail bundle with the same 2 vCPUs and 4 GB is also $24 per month with a public IPv4 address, an 80 GB SSD, and 4 TB of transfer bundled in (Lightsail's IPv6-only version of the same bundle is $20, workable if you only ever connect over a VPN or from IPv6 networks). Budget European hosts price similar shared vCPU plans lower in their EU regions, and big-cloud on-demand instances (EC2, Google Compute Engine) cost more for the same specs but fold into an existing cloud bill. Prices move; check the provider's pricing page before committing.

Step 2: Ten minutes of hardening

An always-on box with your GitHub credentials deserves basic hygiene before any agent touches it. Create a non-root user, allow SSH through the firewall, and turn off password logins so the internet's constant background brute-forcing hits a wall:

# As root, once
adduser dev
usermod -aG sudo dev

# Firewall: SSH only
ufw allow OpenSSH
ufw enable

# Keys only: in /etc/ssh/sshd_config set
#   PasswordAuthentication no
#   PermitRootLogin no
# then restart sshd

# Security patches apply themselves
apt install -y unattended-upgrades

Two optional upgrades are worth knowing about. A mesh VPN such as Tailscale takes the SSH port off the public internet entirely, so only your enrolled devices can reach the box. And mosh keeps your interactive connection responsive on flaky networks, though with tmux in the loop a dropped SSH connection costs you nothing anyway.

Step 3: Install Claude Code

Install the basics, then Claude Code itself with Anthropic's native installer, which needs no Node.js and updates itself in the background:

sudo apt update && sudo apt install -y git tmux
curl -fsSL https://claude.ai/install.sh | bash

The installer puts a launcher at ~/.local/bin/claude that points into ~/.local/share/claude/versions/, where background updates land. Confirm it works (a healthy install prints a version number), and run the built-in diagnostic if anything looks off; claude doctor also reports whether the most recent auto-update succeeded:

claude --version
claude doctor

If you prefer everything to arrive through your package manager, Anthropic also publishes signed apt, dnf, and apk repositories with stable and latest channels; those installs update through your normal system upgrades instead of auto-updating.

Step 4: Sign in over SSH

Claude Code requires a Claude Pro, Max, Team, or Enterprise plan, or a Claude Console account with API billing; the free Claude.ai plan does not include it. Authentication is a browser OAuth flow, and it works fine on a headless server: run claude, and when the login screen appears, copy the login URL (press c if it is not shown) and open it in the browser on your laptop. Because the browser cannot reach the callback server on the remote machine, it shows a login code instead; paste that code back into the terminal at the prompt, and you are in. Credentials are stored on the VM at ~/.claude/.credentials.json with owner-only file permissions (mode 0600), so the login survives reboots and you will not repeat this often. Logins do expire eventually; Claude Code warns you at startup three days before it expires, and running /login renews it. Console users on recent versions can also sign in without creating an API key: Claude Code stores that sign-in as a profile and refreshes it on its own.

For scripts and CI on machines where nobody can complete a browser hop, Anthropic provides a different tool: claude setup-token mints a one-year OAuth token tied to your subscription, which you export as the CLAUDE_CODE_OAUTH_TOKEN environment variable. For an interactive dev box, the normal login above is simpler and is what you want.

Step 5: Run every session inside tmux

This is the step that makes the whole setup worth it. A Claude Code process launched in a bare SSH session dies when the connection drops. Inside tmux, the session belongs to the server, not to your connection:

# Start a named session per task
tmux new -s auth-refactor
claude

# Detach: press Ctrl-b, then d. Close the laptop. Later, from anywhere:
ssh dev-box
tmux attach -t auth-refactor

# See what is running
tmux ls

Name sessions after tasks, not after the tool. When you run two or three agents at once, tmux ls should read like a to-do list. New windows inside one session (Ctrl-b, then c) work too, but separate named sessions are easier to reason about and to kill cleanly. One warning: tmux state lives in memory, so a VM reboot clears every session. That is rarely a problem for day-long tasks, but it means the box is a workbench, not a system of record; anything worth keeping should be committed and pushed.

If you run several agents in one repository, give each its own git worktree so they do not fight over the checkout; our worktrees guide covers the pattern. The same VM happily runs other CLIs alongside Claude Code: the Codex version of this guide covers the OpenAI side, and the self-hosted agent setup guide covers turning one box into a full multi-agent rig. For the broader landscape of ways to keep sessions alive, including VS Code tunnels and managed cloud agents, see keeping Claude Code running after closing your laptop. The August 2026 model releases raise the stakes on persistence: reasoning models like GLM-5.3 no longer let you disable thinking at all, and a long thinking run is exactly the session you do not want tied to a laptop lid.

What this actually costs

The VM is the only new line item. Your Claude usage is billed exactly as before, through the subscription or Console account you logged in with; nothing about running on a server changes model pricing. So the marginal cost of the whole setup is roughly $24 per month at the mainstream providers above, less at budget hosts, for an agent that works while you sleep.

Where a hand-rolled box runs out of road

For one engineer, the setup above is genuinely good, and you should run it. The friction appears at the edges. Sharing a live session with a teammate means sharing SSH access to the box, which most teams rightly refuse to do. Parallel tasks need per-task worktrees you script yourself. Nobody can see what the agents are doing without logging in and attaching, so a stuck agent stays stuck until you happen to check. And each teammate who wants this needs to repeat the whole ritual on a box of their own. Those gaps are exactly what a team product closes.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. It is this guide's setup, operated as a product. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser: sessions survive a closed laptop and resume from any device, and a teammate can open the same workspace and see and steer the same live session instead of asking for SSH keys. Each engineer connects their own Claude or OpenAI account, and AQ never marks up usage on your own subscriptions.

The glue you would otherwise script is built in: every workspace gets an isolated git worktree on a branch named ai/{id}-{slug} with dependencies installed automatically and a one-click rebase onto main, commits and PRs use per-user GitHub auth, opened PRs are tracked per workspace, and each workspace can run a live dev-server preview with shareable links, where comments pinned on the preview (screenshots included) can be sent to the agent as prompts. Teams that plan in Linear can label an issue ai-task and a workspace appears with status syncing both ways. Runner health is visible in the product, the installer runs preflight checks, and an aq-runner doctor command diagnoses a broken host.

Pricing is two plans. The Free plan is a personal sandbox for one person: AQ creates the machine for you, so you skip this guide's setup entirely. Connecting a VM you own, exactly like the one this guide builds, is part of the Team plan at $50 per user per month (promotional; standard $200, billed monthly), which also adds your whole team and a dedicated always-on AQ-managed option, rate locked for your first 12 months. Solo and comfortable in tmux? Keep the hand-rolled box. AQ earns its place when the second engineer wants in.

Frequently asked questions

Can I log in to Claude Code on a server with no browser?

Yes. Run claude over SSH, open the login URL in the browser on your laptop, and the browser shows a login code because it cannot reach the callback server on the remote machine. Paste that code into the terminal prompt and the login completes. Credentials persist on the server in ~/.claude/.credentials.json. For fully unattended machines such as CI, claude setup-token generates a one-year token you export as CLAUDE_CODE_OAUTH_TOKEN.

How big a VM does Claude Code need?

Anthropic's minimum is 4 GB of RAM on x64 or ARM64, running Ubuntu 20.04+, Debian 10+, or Alpine 3.19+. Size for the work around the agent: 2 vCPUs and 4 GB handles the CLI plus a light toolchain, while heavy npm or cargo builds and a running dev server make 8 GB the comfortable choice. On smaller boxes, add a swap file so builds degrade gracefully instead of being killed.

Does Claude Code keep working after I close my laptop?

Only if the process outlives your SSH connection, which is exactly what tmux provides. Start a named tmux session, launch claude inside it, and detach; the agent keeps running on the server. Reattach later from any machine with tmux attach. Without tmux (or screen, or a similar multiplexer), the process is a child of your SSH session and dies when the connection drops.

Do I need an Anthropic API key to run Claude Code on a VM?

No. The normal path is logging in with a Claude Pro, Max, Team, or Enterprise subscription, the same account you use locally. A Claude Console account with API billing also works, and setting ANTHROPIC_API_KEY is an alternative for automation. Note that the free Claude.ai plan does not include Claude Code access, as of October 2026.

How much does it cost to run Claude Code on a cloud VM?

The VM is the only new cost. As of October 2026, a 2 vCPU, 4 GB server runs $24 per month at DigitalOcean or AWS Lightsail, and less at budget European hosts. Your Claude usage is billed exactly as before, through the subscription or Console account you log in with; running on a server changes nothing about model pricing. Budget a few dollars more if you add block storage or a larger instance for heavy builds.

Can multiple people use Claude Code on one VM?

Yes, with one Unix user per person. Each user gets their own home directory, so their Claude login (stored under ~/.claude) and tmux sessions stay separate, and each person authenticates with their own Claude subscription. What a shared box does not give you is visibility: nobody can see anyone else's session without logging into that account. That gap is what team products cover; in AQ, teammates open the same workspace in the browser and watch the same live session, with each person still on their own Claude or OpenAI account.

Can I check on a Claude Code session from my phone?

Yes. Because the session lives in tmux on the server, any SSH client works: install one on your phone (Termius, Blink, or similar), connect to the VM, and run tmux attach to see the live session exactly where you left it. Typing long prompts in a phone SSH client is the painful part. Team products smooth this over; in AQ the same live terminal streams to a mobile browser tab, so checking on an overnight run is opening a URL rather than configuring an SSH key on your phone.

Is it safer to run an agent with relaxed permissions on a VM?

Safer, not safe. A dedicated VM contains the blast radius: a bad command can wreck the box, but not the laptop holding your password manager and browser sessions. The machine still carries real credentials (your GitHub auth, your Claude login), so harden SSH, keep secrets on it to a minimum, and treat it as disposable: anything valuable gets committed and pushed.