Why I Built My Own Agentic Environment on a VPS

TL;DR

AI agents billed by the token get expensive once you use them continuously: monitoring, batch jobs, repeated generation, tests. I rented a VPS at a fixed, predictable cost (roughly €28 all-in per month) to turn it into a permanent agentic work machine, with local models handling the volume and cloud agents stepping in for whatever genuinely needs them. This article opens a long-running experience-report series: what works, what breaks, and the architecture that emerges from it week after week.

---

Table of contents

• The problem: billed by the token, continuously
• A VPS, not just a host
• The stack I'm targeting
• The hardware choice
• Hybrid out of necessity, not ideology
• What this series will document

---

The problem: billed by the token, continuously

Using a cloud AI agent for a one-off task (a refactor, a code review, an architecture question) costs little and pays for itself easily in time saved. The math changes once the usage becomes permanent: automated tech watch, bulk test generation, repetitive data transformations, content classification, overnight batch jobs. Multiply that by dozens of runs a day and the per-token cost stops being negligible. Worse, it stops being predictable.

I didn't want to give up on cloud agents, though. Figuring out where they keep the edge, and where local can hold its own, is exactly what this series is meant to test. I just wanted to stop being forced to reach for them for everything, including simple, repetitive work that can wait.

A VPS, not just a host

The starting idea was modest: rent a permanent Linux machine and use it as a base for my agentic experiments, instead of running everything on my workstation or paying for every single call to an AI provider.

A VPS has an advantage a local machine doesn't: it runs 24/7, it's reachable from anywhere, and it can host long-running processes (background, batch) without depending on my PC being on. That permanence is what gradually turns it into more than a host: a real agentic work machine, capable of running local models and orchestrators.

The stack I'm targeting

The ground this environment needs to cover matches my actual professional usage, not a demo:

• .NET / C#, with F# as an ongoing exploration;
• TypeScript;
• BDD (Gherkin);
• CI/CD (GitHub Actions);
• relational and non-relational databases.

The goal wasn't to build an isolated AI lab, but an environment capable of producing code that actually compiles, tests, and deploys on this stack. That's a more demanding bar than it sounds once you hold a real AI agent to it instead of a demo.

The hardware choice

After comparing options, I settled on an OVH VPS:

• Ubuntu 24.04;
• 8 vCPUs;
• 24 GB RAM;
• 200 GB NVMe storage;
• roughly €28 all-in per month.

That's not an oversized machine for LLM inference. A later article will show just how much of a limiting factor CPU-only inference is for multi-billion-parameter models. I could have gone straight for a GPU instance to remove that limit, at a higher and less predictable monthly cost. I chose the opposite: start on a fixed, modest budget, measure what the CPU can actually do, and only scale the hardware up if the results justify it.

Hybrid out of necessity, not ideology

I didn't try to run everything locally on principle. The guiding idea is more pragmatic: a hybrid setup, where local models (via Ollama) absorb whatever can be slow and asynchronous, and cloud agents (Claude Code, Codex) take over for anything interactive, complex, or that needs to land fast.

That split wasn't decided upfront. It was built, and sometimes corrected, test after test.

What this series will document

I'm not starting from an already-validated architecture that I'm presenting after the fact. I'm starting from the actual experiments, in the order they happened, mistakes included:

• hardening the VPS before letting agents capable of running commands loose on it;
• installing Docker, Ollama, and Hermes, and the traps that aren't obvious at first glance, like truncated context;
• local benchmarks that initially seemed to prove a model "doesn't know how to use tools," before discovering the real problem was elsewhere;
• the gradual move from Hermes toward Dev Containers and a development agent living directly inside the project's own environment.

Every article will follow the same rule: what I tried, why it failed when it failed, what not to repeat, and the path I'd recommend today with hindsight. The point isn't to retrace every detour, just to save readers the time I already lost.

Next week: hardening the VPS before installing the first agent on it.