I built an installer so my coding agents never touch a fresh VPS by hand
vibeps is a one-time installer that turns a fresh Ubuntu VPS into a dev machine my coding agents already understand. The setup script has to install everything. I opened a freshly set up box and Claude Code wasn’t on it, and that’s the whole reason this exists:
the setup script should install everything so the box is fully ready user should not be installing anything manually
When it’s done, the agents know what’s installed and can drive the machine. The idea was to give the agent access to get a domain and deploy right away. I built it for myself, for solo use, and I want to open source it once it’s ready for real work.
It runs in nine steps
Preflight and user setup come first, then the base install: Docker, Caddy, Tailscale, mise with node, python and go, uv, ripgrep, fd, just, gh, swap tuning and backup timers. Docker is in there because all VPS machines lack it, so the install script should carry it.
Then you paste an SSH key, set up Tailscale, and verify you can log in with the key. Only after that does it lock the box down: password login off, the firewall down to 80 and 443, SSH over the tailnet only. Services, the agents (Claude Code and Codex) and a first deploy come last.
Every action is a command with JSON output
Agents get structured results. vibeps orient gives capabilities, projects and a health check in one reply. Agents run in persistent tmux sessions that survive a disconnect, and I open the real terminal with the agent in it. I don’t launch it with -p. When you SSH in, the menu opens right away.
I didn’t want a box full of things nobody asked for
The service catalog is a pick list: postgres, valkey, umami, uptime-kuma. Nothing gets installed unless you select it, and the agent can add one later when it needs it. I wanted fewer dependencies.
Same with the user. A devbox could run everything as root, so I asked why it needs a deploy user at all. I settled on a user, just not one called deploy. The installer asks for the name.
The agent routing design is where I pushed back hardest. It came back with fallback chains, and I said:
no this is too complex and overengineered i think, too much fallbacks chains and stuff
I wanted something easy to change and switch, like profiles. The per-agent skill and workflow setup was already good. I removed the goal feature too, because it was an extra step.
I tested on throwaway machines
OrbStack gives me throwaway Linux machines. I had Codex iterate on them, make new ones, delete them and redo, until the install was fully ready with good UX. The rule was not bloated, clean, not overengineered. That meant resetting a lot of machines.
The installer UX took a few passes. The first terminal UI looked too simple, like it barely had anything. The installer sat on one line so long I couldn’t tell if it was frozen, so it got a loader that moves, plus checklists. Tailscale had to be skippable, because not every user needs it. I also got stuck on the Tailscale step once and didn’t know what to do.
The lockout gate
Step 5 is the gate. It waits up to 180 seconds for you to log in with your key before anything locks down. When I tested it, the output said “gate cleared” and I told the agent “you lied to me.” Then I reset the machine again.
Ctrl C in the installer skips the current step. It doesn’t turn it off, even though the installer is resumable.
The lockdown caught me too. After it ran I could SSH in as my own user, but not as the default ubuntu account anymore. That’s the wrong thing to do to a user who might still need root. I think that account should keep a password, since Tailscale is there anyway.
On a box that’s already running, the rule is that it must not kill the server mid run.