Operations and law

Self-hosting AI agents or paying for hosting: the honest math

What a coding agent with editor, git and terminal really needs: RAM, sandbox, resource limits, keys. And when hosting beats your own VPS.

UltraNOS11 min read

Self-hosting an AI agent is not hard in a technical sense: a Linux server, a Python process, an API key or a local model through Ollama, done. The math often fails anyway, and not because of the hardware. A coding agent that writes files, drives git and has a terminal is a process that runs arbitrary code on your server. Everything that follows (sandbox, memory limits, key management, loop protection, backups) you have to build or operate yourself. This article counts exactly those items, with numbers from our own operation at Hetzner in Nuremberg. It ends with a decision table, not a buying recommendation.

What "agent" means here

The word is used for many things. Here it means the demanding kind: a coding agent that works in a loop.

  • Tools: The agent reads and writes files, calls git, runs commands in the terminal, opens a browser. In UltraNOS that is 7 to 38 tools per session, depending on the mode.
  • Loops: Think, act, check, start over. One turn can take dozens of tool rounds; in long-run mode the number of rounds is no longer capped at all.
  • Sub-agents: The chat agent can start further agents that work in parallel. Our limits: depth at most 2, at most 16 concurrent jobs, callback depth 8.

A chatbot that only returns text needs none of this. An agent with a terminal needs all of it, and each of these points is a place where a server can tip over.

The hardware math

The first question when self-hosting is not "which server" but "where does the model run".

Option A: local model

With Ollama the model runs on your hardware. Upside: prompts never leave the machine, and there is no cost per request. Downside: the model weights plus the context window have to fit in RAM or VRAM, and a coding agent fills its context window fast with file contents and terminal output. The memory figures per model are listed in the model library on ollama.com; for usable coding models they are well above what a small VPS offers.

Option B: API model

The model runs at the provider, and your server only orchestrates. That is how we run it: the UltraNOS production server has 8 GB of RAM and computes no model itself. The memory goes to whatever the agent triggers instead: git clones, npm run build, test runs, Playwright browsers.

An example from our development VM: two Playwright browsers at once for a mobile test, and the kernel's OOM killer clears the table. That is why we measure Firefox and Chromium one after the other. It is the kind of experience that appears in no guide to an "AI agent VPS".

Item Local model API model
RAM for the model Weights + context, per model see ollama.com 0
RAM for agent work (builds, clones, browsers) needed on top for us: the full 8 GB
Cost per request 0 depends on the provider
Prompts leave the server no yes, to the chosen provider
GPU useful yes no

Disk: the underrated topic

A coding agent clones repositories. Our target is that a single 50 GB repo fits without effort. That is why UltraNOS makes the partial clone the default (umfang set to partial, shallow or full, plus sparse paths), and Git LFS is skipped on clone. The workspaces live on a dedicated 145 GB volume that costs about €10 a month and has deletion protection. If you self-host, you have to make this decision too, before the first agent runs git clone on a monorepo.

Security duties nobody takes off your hands

This is where the real effort sits. An agent with a terminal is a user with shell access who never gets tired and may mistake instructions inside files for commands. What we built for this is in the documentation, and every item was a lesson.

Sandbox

Terminal, builds and script execution run in bubblewrap (bwrap) for us, with a purpose-built environment instead of the service's own. The trigger was a finding: the build tab was the last path running without a sandbox, and it passed every provider key through to npm run build with {**os.environ}. A single malicious build script would have been enough.

To be honest, this is not finished either: environment values for the sandbox still end up in the argument list of the bwrap process via --setenv, where unsandboxed host processes could read them. The route through a file descriptor is known and on the list.

Resource limits for every child process

Before every exec, engine/lastgrenzen.py sets hard limits in four profiles (interactive, service, build, short): CPU time, file size, process count, descriptors. Three details you only learn after an outage when building this yourself:

  1. Memory through cgroups, not through RLIMIT_AS. The address-space limit kills Node and the JVM, which reserve large virtual regions without using them.
  2. RLIMIT_NPROC counts in the user namespace, but /proc only shows the PID namespace. On a VM we saw 1001 processes against about 2500 real ones. A fixed formula "visible plus 64" was not a limit there, it was a start-up lock.
  3. PID reuse: Before every group kill, the load watchdog checks the start time from /proc/<pid>/stat. Otherwise, sooner or later the kill hits the wrong process.

Load watchdog

Per-process limits are not enough, because the sum still fills the host. The load watchdog checks free disk space and MemAvailable every 15 seconds, blocks new starts below the reserve, and under memory pressure kills the largest process tree it started itself, before the kernel's OOM killer strikes at random. Every 10 minutes the workspaces are re-measured. Terminal output is throttled to 512 KB/s, and each tenant gets at most 8 terminals.

Loop protection

Agents go in circles. The loop watchdog compares pairs of tool call and result: on the third identical call there is a warning, from the fifth it no longer executes; oscillation between two states is detected separately. Each turn has a time budget, 45 minutes by default. On top come four built-in guards (no-rm-rf, no-force-push, no-drop-table, no-curl-pipe-bash) plus your own regex rules. If you self-host, you have none of this until you write it.

What we have not solved either

Prompt injection is open on our list: the model does not tell data from instructions, and content from cloned third-party repos, emails or web pages can contain instructions. Detection does not work reliably; the achievable step is to put tools with outside effects behind a confirmation. You have this duty on your own server just the same.

Keys: vault and redaction

An agent works with secrets: API keys, git tokens, SSH keys, server passwords. You have to answer two questions when self-hosting.

Where do the keys live? In UltraNOS, in an encrypted vault; twelve services depend on it. A guard (engine/kek_wache.py) aborts the start if the key for decryption is missing but ciphertext exists. Before that, this spot had a silent fresh start, meaning an empty vault with no error message. When building it yourself, a .env file is the usual route, and in our experience it ends up in a chat or a commit sooner or later.

What does the model see? Everything that is in the prompt. In UltraNOS the cloak redaction applies before sending: 27 prefix rules for known providers (sk-ant-…, ghp_…, glpat-…), 13 structural rules for assignments, headers and connection strings, plus email addresses and vault values. A key becomes a placeholder of the form CLOAK_SECRET_…, the model works with that, and the translation back happens only at tool execution. The enforce profile is the default; if the package is missing, the turn fails readably instead of sending plaintext.

The limits are stated too: on the CLI route through Claude Code only the prompt and system prompt are masked, because the CLI runs its tools itself. Unknown formats without a prefix and without context go through. Whether the protection is running is shown by GET /api/health in the cloak field. More on this in Protecting API keys in the prompt.

Cost comparison: VPS versus hosted

Model costs arise in both cases and depend on the provider. The difference lies in server and time.

Item Your own VPS UltraNOS hosted
Server Price per hetzner.com; for agent work with builds, at least the 8 GB RAM class included in the plan
Volume for repos Example: 145 GB about €10/month Starter 200 MB, Pro 5 GB, Team unlimited
Firewall, updates, sandbox, resource limits your time, every month part of operations
Key vault, redaction build it yourself or rely on .env cloak in the enforce profile
Backups set up yourself system disk backed up; the workspace volume is still open on our side (borg is the next step)
Model costs depends on the provider depends on the provider
Price Server + volume + hours Starter €0, Pro €19/month, Team €49/month

The hours are the item everyone underestimates. Put in an honest value for your working time and work out how many hours a month a server with an executing agent needs: kernel updates, a broken build that fills the disk, an agent in a loop that holds the CPU at 100 % overnight. If that number is above the difference to €19, the decision is made.

What "hosted" means concretely here: server location Nuremberg, the web host behind a cloud firewall that lets only ports 80 and 443 in from the internet, data processing agreement available. Prompts still go to the model provider you choose.

Decision guide

If you … then …
want a local model because prompts must not leave the machine self-host with Ollama, on hardware with enough RAM or VRAM
run Linux servers anyway and enjoy cgroups self-host, using the duties list above as a template
want a coding agent with editor, git and terminal but no second job as an admin hosted
work on the same repos as a team hosted (Team) or a seriously maintained own server
first want to see whether agents work for you Starter for €0 at ultranos.de, 14 days of full features to try

If you are looking for Open WebUI and similar interfaces as a pure chat front end, the comparison is in Open WebUI alternatives 2026. That is a different job from an agent with a terminal.

FAQ

How can I build AI agents myself?

At the core you need a model with tool calling, a loop (think, act, check) and the tools themselves: read and write files, run a command, git. That can be built over a weekend. The work starts after that: sandbox, memory and process limits, loop detection, key management. Count these in from the start, or you end up with an agent that fills the server on day three.

Which platform suits AI agents?

That depends on whether you want a library to build with or a ready-made workplace. For building yourself, Ollama plus a framework of your choice is the usual route. UltraNOS is the ready-made workplace in the browser: chat, Monaco editor, git, terminal and agents in one interface, with a freely selectable model provider (Claude via API or CLI, OpenAI-compatible, Ollama, your own endpoint). Self-hosting is optional and available on request.

Can I create an AI agent for free?

The UltraNOS Starter plan costs €0. Whether model costs arise depends on the chosen provider: a local model through Ollama costs nothing per request but needs your own hardware. An agent that really writes and tests code uses far more tokens than a chat, because file contents and terminal output ride along in every turn.

How much RAM does a self-hosted AI agent need?

With an API model, our production runs on 8 GB, and all of it goes to builds, clones and browsers, not to the model. With a local model, the model weights plus the context window come on top; the values per model are at ollama.com. More important than the number is the limit: without a cgroup cap per child process, the OOM killer decides what survives.

Does a coding agent work with a local model through Ollama?

Yes, Ollama can be selected as a provider in UltraNOS, and cloak redaction applies on that route too. Whether the results are any good depends on the model: an agent needs reliable tool calls, and a model without that ability can only talk about a task instead of carrying it out. The model list therefore shows this as a warning.

Who should keep self-hosting

Self-hosting is the right choice if prompts must not leave your own machine, if you have a GPU that is bored, or if running servers is not a chore for you but a hobby. Then the duties list above is no deterrent but a template, and you get a system you understand down to the kernel.

For everyone else, the honest math is this: the server is the smallest item. The time for the protection an executing agent needs is the largest. And anyone who does not believe that can read how many of the points above we only built after an outage.

Your keys stay yours — the rest runs in the browser.

UltraNOS is the agentic web IDE: parallel AI agents, editor, git and terminal. cloak replaces API keys and passwords before a prompt reaches the provider. Hosted in Germany, 14 days free.

Try 14 days free →

Keep reading