Run an AI agent 24/7 on a VPS.
Off your laptop, onto metal that does not sleep.
To run an AI agent 24/7 on a VPS you need four things, none of them clever: a box that stays up, a supervisor that restarts it, secrets that never enter the image, and a spend cap — plus a host that does not require your identity.
- 01
Most agents are I/O-bound glue around a hosted model API. The inference is not on your box, so the box is small: 2 vCPU and 4 GB carry a single-loop agent.
- 02
Uptime is a supervisor problem, not a hardware problem. A systemd unit or a Docker restart policy — enabled, and tested against a real reboot — is the whole of it.
- 03
The two things that actually bite: a secret baked into an image layer, and an agent with no spend ceiling looping all night against a metered API.
Why your laptop is not a deployment. Four failure modes, all of them boring.
An agent that works on your machine is a working agent, not a deployed one. The gap is four unglamorous problems, none of them about prompt engineering.
Sleep. Close the lid and the process is suspended. Power management throttles background work long before the lid closes, which gives the worst version of this failure: an agent that runs, but late and unpredictably.
IP churn. A home or cafe connection hands you a new address on every reconnection. Anything rate-limited by IP, any webhook needing a stable callback, any allowlist you registered breaks intermittently.
Reboots. Operating-system updates restart the machine on their own schedule. Unless the agent is registered with a service manager, it comes back to a desktop, not to a running loop. Most people notice a week later.
Moving. You travel, you switch machines, you reinstall. Anything living only in your shell history is not reproducible — an agent set up one afternoon in March has no deployment procedure at all.
A server fixes these four things and nothing else — not correctness, not cost, not safety. It gives you a runtime whose failures are yours to fix. Be suspicious of anyone selling it as more.
Sizing the box. Which VPS tier for which agent shape.
The instinct is to over-provision, because artificial intelligence sounds heavy. It is not, as long as the model runs on someone else's hardware: an agent calling a hosted API spends its time waiting on network I/O. A third shape — running the model itself — is out of scope here; that workload wants a GPU more than a virtual machine.
Shape one — the single loop. One process, a polling or scheduled loop, a hosted model API, state in SQLite. This is most indie agents and monitoring bots, and it is genuinely small.
Shape two — the small stack. The agent plus Postgres, a Redis-backed queue, a worker and a vector store. Memory is now the binding constraint — an embedding model loaded in-process wants a gigabyte or two of its own.
Against the catalogue: Sentinel (NB-V1 — 2 vCPU, 4 GB RAM, 120 GB NVMe, 1 Gbps, unlimited bandwidth, $3.90/month) covers shape one with room to spare. Garrison (NB-V2 — 4 vCPU, 8 GB, 240 GB, $7.90/month) is the honest floor for shape two once Postgres and a queue are in the picture. Ravelin (NB-V3 — 8 vCPU, 16 GB, 480 GB, 2.5 Gbps, $16.90/month) is for several agents sharing a box. Local inference belongs on dedicated hardware.
Terms run monthly, with a discount on longer commitments — 10% at three months, 20% at six, 30% at twelve. If your agent is a Windows-only trading client rather than a Python process, the remote-desktop tiers exist for that case.
The deploy path — run an AI agent on a VPS in about fifteen minutes.
Provision the box with Ubuntu 24.04 LTS or Debian 13 — both offered at order time, along with Ubuntu 22.04, Debian 12, AlmaLinux 9 and Rocky Linux 9. You get root credentials; the first thing to do with them is stop using them. If SSH key authentication is unfamiliar territory, read the hardening guide linked below first.
1 — Create a service user. adduser --system --group --home /srv/agent agent. The agent should not run as root and should not own an interactive shell. One command now, and the blast radius stays small later if a tool it calls is turned against it.
2 — Get the code onto the box. git clone into /srv/agent, or rsync if you would rather not leave a deploy key on the server. Pin the dependencies: a lockfile is the difference between a redeploy that reproduces and one that surprises you.
3 — Build the environment. python3 -m venv /srv/agent/.venv, then install from the lockfile with that virtualenv's pip. Or install uv and let it manage both the interpreter and the lockfile. Either is fine; mixing the two is not.
4 — Run it once by hand. sudo -u agent /srv/agent/.venv/bin/python -m agent --once. Do not skip this to go straight to a service unit. Nine failures out of ten here are a missing environment variable or a path relative to your laptop, and both read more clearly in a terminal than in journald.
5 — Hand it to a supervisor. The next chapter. This is what turns a script you started into a service the machine owns. If the sequence took materially longer than fifteen minutes, the cause is almost always an implicit dependency on your development machine — a global binary, a credential in your shell profile, a path outside the repository.
Keeping it alive 24/7. systemd, Docker, and the crash-loop trap.
A process you started over an SSH session dies when the session ends, and does not come back after a reboot. Supervision is not optional, and you have two reasonable options.
systemd, for a single process. A unit in /etc/systemd/system/agent.service with User=agent, WorkingDirectory=/srv/agent, ExecStart pointing at the virtualenv interpreter, Restart=always and RestartSec=5. Then systemctl daemon-reload, then systemctl enable --now agent. The enable is what survives a reboot; starting without enabling is the most common way to lose an agent three weeks later.
Docker, for a set of things. When the agent has siblings — a database, a queue, a headless browser — describe them in one Compose file with restart: unless-stopped on each service. unless-stopped differs from always in one respect that matters: a container you deliberately stopped stays stopped across a daemon restart.
The crash-loop trap. systemd rate-limits restarts by default. Crash often enough inside the interval and the unit enters the failed state and stops trying — an agent that appears to have died silently while the unit file plainly says Restart=always. Set StartLimitIntervalSec=0 to retry indefinitely, and raise RestartSec so a broken agent does not spin a core all night.
Liveness is not health. A loop stuck on a socket read for nine hours is a running process by every measure systemd can see. Expose a heartbeat: a watchdog with WatchdogSec, a Docker HEALTHCHECK, or a timestamp file the agent touches each cycle with a timer that alerts when it goes stale.
Secrets. The environment file that must never reach the image.
An agent holds more dangerous material than a web application. A model API key is a spending instrument; a trading key is one with leverage; a wallet key is the funds themselves. And unlike a web app, an agent acts on text it did not write, which makes the boundary between the agent holding a key and an attacker holding it thin.
Keep them out of the image. ENV and ARG values in a Dockerfile are written into image layers and readable with docker history by anyone who obtains the image. Use env_file: in Compose, or EnvironmentFile= in the systemd unit, and keep the file outside the build context.
Keep them out of the repository. .gitignore and .dockerignore on the first commit, not the fiftieth. A key that has ever been committed is compromised even after the commit is rewritten, because the object survives in clones and forks. Rotate it rather than rewriting history.
Restrict what the file can reach. Own the environment file to the service user and set mode 600. Combined with a non-root service user, a compromised dependency elsewhere on the box cannot simply read your keys off disk.
Scope each key at the issuer. One key per agent, with the narrowest permissions the provider offers — read-only where reads suffice, withdrawal disabled on exchange keys, IP-allowlisted to the server. A stable IP is a quiet advantage of moving off a laptop: allowlisting is finally possible. If several people need the same credentials, put them behind the self-hosted vault in the companion guide.
Scheduling. Loops, timers and the timezone that bites you.
Running continuously describes three different architectures, and choosing the wrong one is a common source of duplicated work and missed runs.
The resident loop. One long-lived process that sleeps between cycles. Simplest to reason about, and the right default. Its weakness is state: everything in memory is lost on restart, so anything that must survive a crash belongs in SQLite or Postgres, not in a variable.
The scheduled run. A process that starts, does one unit of work and exits. A systemd timer with OnCalendar is the better tool here, mainly because of Persistent=true: after downtime, a persistent timer fires the run it missed, whereas cron simply skips it.
The queue. A producer enqueues tasks, workers consume them. This is what you want the moment tasks arrive faster than they complete. It also gives you retries, dead-letter handling and a concurrency ceiling.
Two rules whatever you pick. Make every task idempotent — a supervisor that restarts on crash will retry tasks, and a retried task must not double-post or double-order. And leave the server clock in UTC, converting only at the edges: a schedule that shifts by an hour twice a year is a tedious bug to find.
Giving the agent tools. A tool server on the same box.
An agent without tools is a chat loop. The tools are what let it read a repository, query a database, place an order or file an issue — and once the agent lives on a server, so should they.
The Model Context Protocol has become the common way to expose those tools, and a server you run privately is easy to put next to the agent: same box, same private interface, no public exposure needed. The companion guides cover it properly — hosting a remote MCP server walks through TLS, the streamable-HTTP transport, OAuth and the agent card, while the no-ID hosting angle covers the same stack from the identity side.
Bind it to localhost first. If the only consumer is the agent on the same machine, the tool server has no reason to hold a public port. Bind to the loopback address and skip the certificate. Expose it publicly only when a second machine needs it — and then it needs TLS and authentication, not one of the two.
Give tools the least authority that works. The agent decides which tool to call based on text, and some of that text comes from outside. Prompt injection is not hypothetical for an agent reading web pages or inboxes: it is the expected case. A tool that can only read cannot be talked into writing. Where a tool must write, make destructive paths require a human confirmation.
If you are building tools for other people's agents rather than your own, the machine API and the agent-facing surface document how this platform exposes provisioning to an agent directly.
Observability and cost. What to log, and the runaway kill-switch.
Two failure modes dominate real agent deployments, and neither is a crash. One is the agent that runs perfectly and produces nothing useful. The other is the agent that runs perfectly and produces a four-figure API bill overnight.
Log the shape, not the content. Timestamp, task id, step count, tool names invoked, token totals, duration, outcome. That answers every operational question you will actually ask. Full prompts and completions are a transcript of everything the agent has ever been asked to do, in plaintext, on a disk in someone else's building.
Cap retention. journald keeps growing until you tell it not to. SystemMaxUse and MaxRetentionSec in journald.conf put a ceiling on both size and age. A chatty agent fills a disk in weeks otherwise, and a full disk fails in ways much harder to read than a clean crash.
Three layers of spend control. At the provider, a hard cap on the API key — the only limit no bug in your code can bypass, and the one people skip. In the agent, a token counter per run with an abort threshold. Around the agent, a maximum step count and a wall-clock timeout, so a model arguing with itself stops after twenty iterations rather than four thousand.
Build the kill-switch before you need it. One command that stops everything: systemctl stop agent, or docker compose down. Make sure it does not require a laptop with a specific key on it. The difference between a bad night and a bad month is whether stopping a runaway takes ten seconds or an hour.
The identity floor. What the host knows — and what it cannot protect you from.
An agent is a long-lived process with credentials, acting on your behalf from a stable address, continuously. That makes the rental record more interesting than for a static website: it is doing things attributable to you, every hour, for months.
The floor here is an email address and a password to sign up, payment in eight assets — Bitcoin, Ethereum, Tether on two chains, Monero, Litecoin, TRON and Solana — and no identity document at any stage. The data centres sit in four Nordic constitutional regimes: Stockholm, Helsinki, Oslo and Reykjavík. The operating doctrine sets out what is retained; the network page covers routing.
Now the limit, which matters more than the pitch. A host that asks for no identity removes the rental record. It does not touch the inference layer: your agent authenticates to a model provider with a key tied to an account, from a stable IP, on every call. If that account is in your legal name — and for most people it is — the identity is established there regardless of who rents the metal. The host layer removes one link: a real one, and only one.
What follows is unglamorous. Compartmentalise: one agent, one server, one key, one wallet. Harden the box on day one rather than day thirty — the first-hour checklist is an hour well spent on a machine that runs unattended for months. If the agent must reach a private network, terminate it on the server with a tunnel rather than exposing services — the tunnel guide covers the configuration. And pay in crypto from a wallet that is not the one your agent trades from.
None of this is exotic, and none of it is a guarantee. It is the ordinary discipline of running something that acts on your behalf while you are asleep — which is all that continuous operation means. The rest of the cluster is on the guides index.
Questions, answered.
Seven questions developers ask before moving an agent off localhost — and in the first month after.
How much VPS do I need to run an AI agent 24/7?
Less than people expect, because inference happens on the provider's hardware, not yours. An agent that calls a hosted model API and runs a polling loop is an I/O-bound process: the Sentinel tier (2 vCPU, 4 GB RAM, 120 GB NVMe, $3.90/month) is a comfortable fit. Move up to Garrison (4 vCPU, 8 GB, $7.90/month) once you add Postgres, a queue and a local embedding model.
Should I use systemd or Docker to keep the agent running?
Either works; the failure modes differ. A systemd unit with Restart=always is the shortest path for a single process and gives you journald, resource limits and boot ordering for free. Docker with restart: unless-stopped is better when the agent has siblings, because Compose describes the whole set in one file. What matters more is that you actually enable it, and test a reboot before walking away.
Why does my agent stop restarting after a few crashes?
Because systemd rate-limits restarts. StartLimitBurst and StartLimitIntervalSec allow a small number of restarts inside a short window; exceed them and the unit enters the failed state and stays there, which looks exactly like a silent death. Either fix the underlying crash — the correct answer — or set StartLimitIntervalSec=0 to disable the limiter and RestartSec=10 so a crash-looping agent does not burn a core retrying.
Where do I put the API keys?
In a file the container image never sees. Keep an environment file outside the build context, referenced by EnvironmentFile= in the systemd unit or env_file: in Compose, owned by the service user with mode 600. Never use ENV or ARG in a Dockerfile for a secret: those values are baked into image layers and readable with docker history. Add the file to .gitignore and .dockerignore before the first commit.
How do I stop an agent from spending my entire API budget overnight?
Three layers, and you want all three. At the provider: a hard spend cap on the API key, the only limit no bug in your code can bypass. In the agent: count tokens or calls per run and abort above a threshold. Around the agent: a step ceiling per task and a wall-clock timeout. No host can do this for you — a VPS is rented capacity, not a budget guard on someone else's API.
What should I never write to the agent logs?
Full prompts and completions, raw tool arguments, API keys, wallet material and anything a user typed. Log the shape of the run instead: timestamp, task id, step count, tool names, token totals, duration, outcome. A verbose agent log is a transcript of everything the agent was ever asked to do, in plaintext, on a disk you do not physically control.
Does a KYC-free host make my agent anonymous?
No, and it is worth being precise. A no-ID signup and a crypto payment mean the host has no legal identity to attach to the server. It does nothing about the model provider: your agent authenticates to that API with a key tied to an account, from a stable server IP, on every call. The host layer removes one link in the chain — the rental record — and that is all it removes.
Rent a KYC-free VPS, pay in crypto, move the agent off your laptop tonight.
Sentinel — 2 vCPU, 4 GB RAM, 120 GB NVMe, unlimited bandwidth, $3.90/month — carries a single-loop agent with room for its tool server alongside. An email address and a password to sign up; no document at any stage.
Last reviewed · 2026-08-24 · Sources · systemd.service, systemd.timer and journald.conf manual pages, Docker restart-policy and Compose documentation, Model Context Protocol specification, NordBastion catalogue · Cadence · yearly
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Docker Compose, PostgreSQL, working webhooks — automation you own.
Ollama on CPU, no GPU — what fits in 4, 8, 16 or 32 GB.