Most AI agents do not need a GPU. If your agent calls a hosted model through an API, the server it runs on spends its time waiting on network responses, parsing JSON, calling tools and writing results to a database. That is ordinary CPU and memory work, and a modest VPS for AI agents handles it well. This guide covers how to choose and set up a US server for that job, how to keep API keys safe, how to keep workers running unattended, and the point where you should move to GPU hardware instead.
What an agent server actually does
Before picking a size, it helps to be clear about the workload. A typical LLM-backed agent or worker loop looks like this:
- Pull a task from a queue, a schedule, a webhook or a chat message.
- Build a prompt and send it to a model provider's API over HTTPS.
- Wait for the response, which can take seconds.
- Run the tool calls the model asked for: fetch a page, query a database, call another API, write a file.
- Store the result and pick up the next task.
Most of the elapsed time is spent waiting on remote systems while the CPU sits idle. So a small server can run many agents in parallel with async I/O or several worker processes, and the resource that runs out first is usually RAM, especially if your tools launch a headless browser or load large documents.
Why put the server in the United States
Location matters less for agents than for a game server, but it still counts:
- Your model provider and your other APIs are in the US. Many hosted LLM endpoints and SaaS APIs your agent calls are served from US regions. Keeping the worker close to them shortens each round trip, which adds up when one task makes dozens of calls.
- Your data and users are in North America. If the agent reads from a US database or answers US customers, putting it in the same region keeps the whole chain short.
- East or west. Cloudj offers US cloud servers in New York, Los Angeles, Santa Clara, Seattle, Chicago, Dallas, Atlanta and Miami. Pick the city nearest to the services you call most. If you are unsure, the US VPS buying guide walks through the trade-offs between coasts, and the Americas regional guide compares the US with Canada and other locations.
Sizing a CPU-only agent VPS
Cloudj US servers start at 1 vCPU, 1 GB RAM and 20 GB disk and go up to custom sizes of 104 vCPU and 512 GB RAM, with 30 ready-made plans per location or your own mix of vCPU, RAM and disk. A practical way to choose:
| Workload | Starting point | What to watch |
|---|---|---|
| One bot or a few scheduled agents, pure API calls | 1 to 2 vCPU, 1 to 2 GB RAM | Memory if you add a local database |
| Many concurrent agents with a queue and Redis or PostgreSQL | 2 to 4 vCPU, 4 to 8 GB RAM | Database memory, open connections |
| Agents that drive a headless browser for tool use | 4 vCPU or more, 8 GB RAM or more | Each browser instance can use hundreds of MB |
| Embedding or reranking small models on CPU | Dedicated CPU, 8 GB RAM or more | Sustained CPU usage, disk for model files |
Cloudj offers three CPU types. Shared ("Availability") CPU is fine for agents that wait on APIs most of the time. General purpose suits a mixed stack. Dedicated CPU gives you dedicated cores for steady, CPU-heavy work, which is what you want if you run local embeddings or text processing around the clock.
Start small: you can resize CPU and RAM and grow the disk later from the console.
Setting up the worker
The following steps assume Ubuntu or Debian, which are both available as images.
Create a user and lock down SSH
Deploy with an SSH key, then create a non-root user for the agent so a bug in your code cannot touch the whole system:
adduser --disabled-password agent
mkdir -p /opt/agent && chown agent:agent /opt/agent
ufw allow OpenSSH
ufw enableAgents that only make outbound calls need no other inbound port; put webhook receivers behind a reverse proxy with TLS.
Store API keys outside the code
Never commit model API keys to your repository or bake them into a custom image. Put them in a file only the service user can read:
install -m 600 -o agent -g agent /dev/null /etc/agent.env
nano /etc/agent.envInside, one variable per line, for example LLM_API_KEY=... and DATABASE_URL=.... Use a separate key per server or per project at your model provider, so you can revoke one without breaking everything, and set spending limits on the provider side. An agent loop with a bug can make thousands of calls overnight.
Run it as a systemd service
A service restarts automatically after a crash or a reboot:
cat > /etc/systemd/system/agent-worker.service <<'EOF'
[Unit]
Description=LLM agent worker
After=network-online.target
[Service]
User=agent
WorkingDirectory=/opt/agent
EnvironmentFile=/etc/agent.env
ExecStart=/opt/agent/venv/bin/python worker.py
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now agent-worker
journalctl -u agent-worker -fTo run several workers, use a template unit ([email protected]) and start agent-worker@1, agent-worker@2 and so on, or run them as containers with a restart policy if you prefer Docker.
When load grows, add a proper queue (Redis or a PostgreSQL jobs table) before adding servers. It lets you retry failed tasks, rate-limit to your API quota, and later add a second VPS that pulls from the same queue.
Keeping costs and runaway loops under control
Agent costs come from two places: the server and the model API. On the server side, Cloudj lets you pay by the hour from your account balance or prepay a 1, 3, 6 or 12 month term. Hourly billing suits experiments and short batch runs, but note that an hourly server is charged while it exists, running or stopped, because the disk and IP stay reserved. Delete it when the experiment ends. For an agent that runs every day, a monthly plan with its included traffic allowance (5 TB per month in the US) is simpler to budget. See live prices on the pricing page.
On the API side, log token usage per task, cap the steps an agent can take per run, and watch the console's CPU, RAM and network metrics for a stuck loop.
When a VPS is not enough
A CPU-only VPS is the wrong tool when you want to run the model yourself. Serving an open-weight LLM, fine-tuning, or running image and speech models at any useful speed needs GPU memory. In that case, keep the agent orchestration on a cheap VPS and move inference to GPU cloud servers, or keep using a hosted API. Splitting the two keeps your always-on part small and lets you scale the expensive part only when needed.
Agents that collect data from the web have their own concerns: crawl rates, site rules and when to add dedicated IPs. The web scraping VPS guide covers that side. If your automation is a trading bot rather than an LLM agent, the New York forex VPS article is the closer match.
FAQ
Do I need a GPU to run AI agents?
No, not if the agent calls a hosted model API. The VPS only orchestrates calls and runs tools, which is CPU and memory work. You need a GPU only to run models yourself.
How much RAM does an agent VPS need?
A single API-based agent runs comfortably in 1 to 2 GB. Add memory for a local database, a queue, or headless browsers, which are the usual reasons to move up.
Can I run agents on a Windows server?
Yes, Windows images are available, with a monthly licence fee shown in the console before you deploy. Most agent frameworks are developed on Linux, so Ubuntu or Debian is usually the simpler choice.
Which US city should I pick?
The one closest to the APIs and databases your agent calls most. If they are spread out, a central or east coast city is a reasonable default.
Deploy your agent server
Pick a US city, start with a small shared or general purpose plan, and resize when your metrics say so. You can deploy in a few clicks in the Cloudj console, which shows the exact price before you confirm.