Run a coding AI agent on a VPS

Why run a coding agent on a VPS

A coding agent is a tool that reads your codebase, writes changes, and runs commands to test them, all from the terminal. Running one on a VPS has three advantages over your laptop: it keeps working after you disconnect, it sits right next to your code and your build tools, and it can talk to a model you host yourself. Start it inside a tmux session and you can close your laptop and pick the work back up later, the same pattern as running Claude Code on a VPS with tmux.

Two terminal-based agents are worth knowing. Aider is the terminal-native, git-first option: it auto-commits each change with a sensible message, so your history stays clean and every edit is reversible. It is one of the longest-established terminal coding agents, though its release pace has slowed. Goose, from Block, is broader: an Apache-2.0 agent with a large extension ecosystem and support for many providers including local Ollama models, now developed under the Linux Foundation's Agentic AI Foundation (AAIF). Aider suits a disciplined, git-centric workflow; Goose suits a more general assistant with a wide plugin set.

What you need

You need a VPS with git, tmux, and a recent Python for Aider, or the Goose installer for Goose. And you need a model: either a hosted API key from a provider like Anthropic or OpenAI, or a local model served by Ollama on the same VPS. The self-hosted route keeps your code on your own server and costs nothing per token, at the price of needing enough memory for a capable model.

Install and run Aider

Install Aider in an isolated environment with pipx, which comes from apt because Ubuntu 24.04 blocks plain pip install outside a virtual environment (PEP 668). Then run Aider inside your project, in a tmux session so it survives a disconnect:

sudo apt install pipx
pipx ensurepath
pipx install aider-chat
tmux new -s aider
cd ~/my-project
aider

One version note: this install works as shown on Ubuntu 24.04. On Ubuntu 26.04 it currently fails, because Aider's pinned dependencies include an older numpy that does not build against 26.04's Python 3.14. The fix is to give Aider its own Python 3.12:

pipx install --python 3.12 --fetch-missing-python aider-chat

pipx downloads a standalone interpreter just for Aider, and the install completes. This is a symptom of Aider's slowed release pace; if it bothers you, Goose is the more actively maintained pick.

Once it is running, detach from the session with Ctrl-b then d and the agent keeps working with your laptop closed; reattach later with tmux attach -t aider to read what it changed. Aider reads your repository, proposes edits, applies them, and commits each one, and it can pull in extra files for context when a change spans several of them. Because every change is a commit, undoing the agent is a plain git revert, which is the safety net that makes it comfortable to use. Goose installs with its documented one-line script and runs similarly from the terminal, driving tasks through its extensions:

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

Hosted model or self-hosted model

A hosted model gives you the best quality and needs no local hardware, but it costs money per token and your code is sent to the provider. A self-hosted model through Ollama keeps everything on your server and is free to run once the hardware is paid for, but a coding model good enough to be useful needs real memory. That is the trade to weigh: quality and convenience against privacy and cost.

If you go self-hosted, the practical question is which model fits your server. Size it before you download an eight-gigabyte model onto a box that cannot hold it:

Safety: it edits files and runs commands

A coding agent is not passive. It rewrites files and can run build and test commands, so give it the same care you would give any process that can change your system. Three habits cover most of the risk. Work inside a git repository, so every change is tracked and reversible, which Aider does for you automatically. Run the agent as your ordinary unprivileged user, never as root, following least-privilege users, so a bad command cannot touch the whole system. And keep the box itself hardened, because a coding VPS is still a public server: key-only SSH, a default-deny firewall, and the rest. The OpenClaw hardening guide takes the same stance for a more autonomous agent, and the principles carry across.

To wire a coding agent into your own workflow, building an AI agent with Claude shows how one model drives your tools; running Google's Gemini CLI on a VPS is another terminal option, and self-hosting OpenHands is the heavier autonomous route.

FAQ

Can I run a coding agent with a local model instead of a paid API?

Yes. Both Aider and Goose work with local models served by Ollama, so you can run a coding agent fully self-hosted with no per-token cost and no code leaving your server. The catch is memory: a model capable enough to write useful code needs a good deal of RAM or VRAM, so size the machine to the model before you commit.

Aider or Goose, which should I use?

Pick Aider if your workflow is terminal- and git-centric and you want the most mature, lowest-overhead option; it auto-commits every change so your history stays reversible. Pick Goose if you want a broader assistant with a large extension ecosystem and support for many providers. Both run from the terminal and both work with Ollama, so either suits a VPS.

How much memory do I need for a self-hosted coding model?

It depends on the model's size and how much it is quantized. A small quantized model can run on a few gigabytes, while a stronger model wants far more, and long context windows add to it. Use the sizing tool above to estimate the memory a given model and context length need before you download it.

Is it safe to let an AI agent edit my code and run commands?

It is manageable with the right habits. Keep your work in a git repository so every edit is a reversible commit, run the agent as an unprivileged user rather than root, and harden the VPS as you would any public server. Review the changes it commits rather than trusting them blindly, especially any command it wants to run against your system.