What an AI agent VPS actually needs

TL;DR: Most agent frameworks are not compute-heavy. The model inference usually happens at an API provider, so your server is orchestrating: making HTTP calls, waiting, parsing responses, and running tools. A 2 vCPU, 4GB VPS handles that comfortably for most workloads.

What people underestimate is everything other than compute. Agents hold credentials for the services they act on. They frequently execute code or shell commands. They make unbounded outbound requests, which is both a cost and a security surface. An agent host is one of the most privileged machines you will run, and the specification question is far less interesting than the isolation question.

What the server is actually doing

The mental model matters, because it determines whether you are sizing for a heavy workload or a light one.

In the common architecture, your server runs an orchestration layer. It receives a trigger, assembles a prompt, calls a model provider's API over HTTPS, waits for a response, parses it, decides whether a tool should be invoked, runs that tool, and loops.

Most of that is waiting on network I/O. The CPU work is JSON parsing and control flow, which is cheap.

What is actually expensive:

Tool execution. If a step runs a headless browser, processes a document, executes generated code or transforms a large dataset, that step is the workload. The agent framework is not.

Concurrency. One agent run is trivial. Fifty concurrent runs, each holding an open connection and a context in memory, is a different profile.

Context size in memory. Long conversation histories and large retrieved documents held in process memory add up, particularly when several runs are active.

Retrieval and embeddings, if you run a vector store locally rather than as a service.

What is not expensive: the model inference itself, because it is not happening on your machine. This is the distinction that determines everything, and the picture changes completely if you run models locally, which is a separate exercise covered in the self-hosted LLM guide.

So the honest framing: for API-backed agents, you are sizing a moderately busy web application, not a machine learning workload.

Sizing for orchestration, not inference

1 vCPU, 2GB. Enough for a single agent running occasionally, with lightweight tools. Adequate for experimentation and personal automation. Not enough once you add a database, a queue and any concurrency.

2 vCPU, 4GB. The realistic production floor for most agent workloads. Runs the orchestration layer, a database for state, a queue, and modest concurrency comfortably. This covers the large majority of small business agent use.

4 vCPU, 8GB. Needed once you run browser automation, process documents at volume, handle meaningful concurrency, or run a local vector store alongside everything else.

8 vCPU, 16GB and beyond. Heavy concurrent workloads, substantial local retrieval, or several agent systems on one host.

The specific things that push you up a tier:

Headless browser tools. A browser instance is a heavy process, and several concurrent ones will exhaust a small server quickly. If your agent browses, size for the browser rather than the agent.

Document processing. Parsing large PDFs, extracting and transforming content, and generating embeddings are memory-intensive in bursts.

Local vector databases. Storing and searching embeddings locally consumes memory proportional to your corpus.

Long-running agent loops holding context in memory for extended periods.

Add swap regardless. Agent workloads are bursty by nature, and swap converts a memory spike into slowness rather than an out-of-memory kill, as covered in the new VPS checklist.

Bandwidth deserves a thought. Agents making many API calls and fetching web pages consume more egress than a typical application. Check what your plan includes.

When you actually need more

Three situations genuinely change the calculation.

Running models locally. If inference happens on your hardware rather than at an API, you are in a completely different regime requiring substantial RAM or a GPU. Do not conflate the two workloads when planning.

High concurrency with long-running tasks. An agent that takes two minutes per run, running fifty at once, means fifty concurrent processes each holding memory. This is a queueing and worker-sizing problem more than a raw capacity one, and the answer is usually a job queue with a bounded worker pool rather than a bigger machine.

Browser-based automation at scale. Browser instances are the single most demanding common tool. If this is core to your workload, size specifically for it and consider a dedicated browser service rather than running instances inline.

What does not require more: more agents defined, more tools available, larger prompts, or a more capable model. Those affect your API bill rather than your server.

The security model is the real problem

This is where agent hosting differs meaningfully from ordinary application hosting, and where most of the risk sits.

Agents hold credentials. For an agent to act on your behalf it needs access: API keys, database credentials, OAuth tokens, service accounts. A single agent host frequently holds credentials for more systems than any other machine you run.

Agents execute untrusted content. The core problem is that model output is influenced by input, and input frequently comes from outside your control: a web page the agent fetched, an email it read, a document a user uploaded. Instructions embedded in that content can influence what the agent does next.

This is prompt injection, and it is not a solved problem. Treat model output as untrusted input to whatever it touches, in the same way you would treat a form submission.

Agents run code. Many frameworks include code execution as a tool, which means arbitrary code running on your server, generated by a model that was influenced by content you did not write.

Agents make outbound requests. Which means data can leave, and the destination is decided at runtime.

The practical consequence: an agent host should be treated as a machine that will eventually run something you did not intend, and architected so that when it does, the damage is bounded. That means isolation, least privilege, and egress control rather than trusting the agent to behave.

If your agent has your production database credentials, full outbound network access and code execution enabled, you have built something with a very large blast radius.

Sandboxing code execution

If your agent executes code, isolate it. The framework's own guardrails are not a security boundary.

Run code in a separate container, not in the agent process. A container with no credentials mounted, no access to your internal network, a read-only filesystem except for a scratch directory, dropped capabilities, and hard CPU and memory limits.

Give the sandbox its own network policy. Ideally no outbound access at all, or an explicit allowlist. Code execution that can reach the internet can exfiltrate anything it can read.

Set execution timeouts. Generated code loops. Without a timeout, one run consumes a worker indefinitely.

Use a fresh sandbox per run. State persisting between runs means one contaminated run affects the next.

Do not mount your application directory. The sandbox should not be able to read your source, your configuration or your environment file.

Consider stronger isolation for higher stakes. Containers share a kernel, so a kernel exploit crosses the boundary. For genuinely untrusted execution, lightweight virtual machines or a hosted sandboxing service provide stronger separation than a container does.

Verify what the sandbox can reach. From inside it, attempt to connect to your database, your internal services and an arbitrary external address. If any succeed and should not, the isolation is theoretical.

Workload	vCPU / RAM	Main constraint	Sandboxing need
Single scheduled agent, API tools	1 / 2GB	Nothing much	Low if no code execution
Small business automation, few agents	2 / 4GB	Concurrency	Medium
Agents with code execution	2–4 / 4–8GB	Sandbox overhead	High, isolate properly
Browser automation	4 / 8GB+	Browser instances	High
Document processing at volume	4 / 8GB	Memory bursts	Medium
Local vector store + agents	4–8 / 8–16GB	Corpus size in memory	Medium
Local model inference	See LLM guide	VRAM or RAM	Separate concern
High concurrency, long tasks	Queue + workers	Worker count	Depends on tools

Credential isolation

The single highest-value architectural decision.

Least privilege per integration. An agent reading orders needs read access to orders, not administrator access to the database. Create dedicated credentials scoped to exactly what the agent does. This is tedious and it is the difference between a contained incident and a total one.

Never put credentials in prompts. They end up in logs, in provider-side request records, and potentially in model output. Tools should hold credentials; the model should never see them.

Keep credentials out of the sandbox. Code execution should not have access to the environment holding your keys. This means the credential store lives in the orchestration layer, and the sandbox receives data rather than access.

Use short-lived tokens where the service supports them.

Separate read and write paths. An agent that only needs to read should not hold credentials capable of writing. Where an agent must write, consider requiring human approval for consequential actions rather than granting unattended write access.

Rotate on a schedule and immediately after any suspicious behaviour.

Log every tool invocation with its parameters, so you can reconstruct what an agent actually did. This is essential for incident investigation and it is frequently absent.

Assume the agent will eventually be manipulated. Design so that the worst thing it can do is acceptable. If the answer is "delete our customer database", change the permissions rather than trusting the prompt.

Egress control and cost containment

Two problems that share a solution.

Cost. Agent loops can run away. A misconfigured retry, a loop that does not terminate, or an agent that decides more calls are needed can produce a surprising API bill overnight. This happens to people regularly and the first indication is usually the invoice.

Controls: set spending limits at the provider where available. Cap iterations per agent run in your own code. Set a maximum token budget per run. Log and monitor spend daily rather than monthly. Alert on unusual call volume.

Data leaving. An agent with unrestricted outbound access can send data anywhere, and the destination is chosen at runtime based on content you may not control.

Controls: default-deny outbound from the sandbox with an explicit allowlist for the model provider and any required services. Log outbound destinations. Be deliberate about which internal services the agent can reach — an agent that does not need your database should not be able to route to it.

Rate limiting your own agents. A bounded queue with a fixed worker count prevents a burst of triggers from producing a burst of API calls and a burst of memory consumption simultaneously.

Timeouts everywhere. On model API calls, on tool execution, on the overall agent run. A hanging external call occupies a worker indefinitely, which is the same failure mode that exhausts PHP worker pools.

Separate development from production credentials and budgets, so an experiment cannot consume the production allowance.

Operating an agent host

Treat it as high-value infrastructure. It holds more credentials than most machines you run. Harden it accordingly: SSH keys only, no root login, firewall permitting only what is needed, automatic security updates, fail2ban.

Do not expose the orchestration UI publicly. Whatever interface manages your agents can read credentials and change behaviour. Bind it to a VPN interface rather than publishing it, using the pattern in the WireGuard guide.

Verify what is actually listening. Docker publishes ports past firewall rules routinely, so check bound interfaces directly and scan from outside, as covered in the Docker sizing guide.

Log comprehensively. Every agent run, every tool invocation with parameters, every outbound destination, every credential used. Ninety days minimum, shipped off the server. If an agent does something unexpected, this log is the only way to reconstruct it.

Monitor cost and volume daily. Not as an accounting exercise but as an anomaly detector; a sudden spike in calls is often the first sign of a loop or a manipulation.

Back up state and configuration. Agent definitions, tool configurations, and any database holding run history or credentials. Encrypt backups, since they contain keys, and store the encryption key separately.

Review permissions quarterly. Agents accumulate access as capabilities are added, and nobody removes it afterwards.

Have a kill switch. A documented, tested way to stop all agent execution immediately. When something is going wrong at three in the morning, you want a single command rather than an investigation.

FAQs

What server specs do I need to run AI agents?

For agents calling a model provider's API, 2 vCPU and 4GB of RAM is the realistic production floor, since your server is orchestrating rather than doing inference. Move to 4 vCPU and 8GB if you run headless browsers, process documents at volume, or maintain a local vector store. Running models locally is a different workload entirely.

Do AI agents need a GPU?

Not if inference happens at an API provider, which is the common architecture. Your server is making HTTP calls and running tools, which is ordinary application work. A GPU is only relevant if you run models on your own hardware, which is a separate decision with very different requirements.

What actually uses the most resources on an agent host?

Tool execution rather than the agent framework. Headless browser instances are by far the heaviest common tool, followed by document processing and local embedding generation. The orchestration layer itself, making API calls and parsing responses, is cheap and mostly spent waiting on network I/O.

Is it safe to let an agent execute code?

Only in a properly isolated sandbox: a separate container with no credentials, no internal network access, a read-only filesystem, hard resource limits, execution timeouts and a fresh instance per run. The framework's own guardrails are not a security boundary. For higher stakes, lightweight virtual machines provide stronger isolation than containers.

What is prompt injection and why does it matter for agents?

Model behaviour is influenced by input, and agents routinely process content from outside your control such as fetched web pages, emails and uploaded documents. Instructions embedded in that content can influence what the agent does next. Treat model output as untrusted input to whatever it touches, and bound permissions so that manipulation has limited consequences.

How should I store credentials for an AI agent?

In the orchestration layer, never in prompts and never inside the sandbox. Use dedicated credentials scoped narrowly to what each integration actually needs, prefer short-lived tokens where supported, separate read from write access, and log every tool invocation. Assume the agent will eventually be manipulated and design so the worst outcome is acceptable.

How do I stop an agent running up a huge API bill?

Set spending limits at the provider, cap iterations per agent run in your own code, set a maximum token budget per run, and monitor spend daily rather than monthly. Runaway loops are common and the first indication is usually the invoice, so an alert on unusual call volume is worth more than a monthly review.

Should my agent have internet access?

The orchestration layer needs to reach your model provider and any required services. The code execution sandbox should default to no outbound access with an explicit allowlist, because code that can reach the internet can exfiltrate anything it can read. Log outbound destinations either way.

Can I run agents on shared hosting?

Generally no. Agents are long-running processes, frequently need Docker for sandboxing, require background workers, and often need software the control panel cannot install. This is a VPS workload, and the isolation requirements alone make shared hosting unsuitable.

How much bandwidth do AI agents use?

More than a typical application, since they make many API calls and often fetch web pages. Model API responses can be substantial for long outputs, and browser-based tools download full pages including assets. Check your plan's transfer allowance and what overage costs before assuming it is unlimited.

Do I need a queue for agent workloads?

Once you have any meaningful concurrency, yes. A bounded queue with a fixed worker pool prevents a burst of triggers from simultaneously exhausting memory, saturating your API rate limits and producing a cost spike. It is a better answer than a larger server for the concurrency problem.

What should I log on an agent host?

Every agent run, every tool invocation with its parameters, every outbound destination and every credential used, retained for at least ninety days and shipped off the server. When an agent behaves unexpectedly, this is the only way to reconstruct what actually happened, and it is the most commonly missing piece.

Conclusion

The specification question has a boring answer: 2 vCPU and 4GB covers most API-backed agent workloads, and what pushes you higher is your tools rather than your agents. Headless browsers are the expensive thing, not the orchestration.

The interesting question is architecture, and it is the one worth spending your time on.

An agent host concentrates credentials, executes content it did not author, and makes outbound requests to destinations chosen at runtime. Those three properties together mean you should design for the assumption that something will eventually go wrong, and bound what happens when it does.

Concretely: scope every credential to the minimum the integration needs. Keep credentials out of prompts and out of the sandbox. Default-deny outbound from the execution environment. Cap iterations and token budgets so a loop costs you rupees rather than a month's budget. And log every tool call with parameters, because without that you cannot reconstruct an incident at all.

Then build the kill switch and test it once, while nothing is wrong.

The gap between a well-architected agent host and a careless one is not performance. It is whether a manipulated run means a confusing log entry or a deleted database.

HostCloud runs Linux VPS plans from ₹999 a month on NVMe with full root access, Indian data centres and snapshot backups, which gives you the isolation and control this workload requires. Details at https://hostcloud.in.