One API-backed agent with light tools, low traffic and no local vector database.
always-on AI service
How to Host an AI Agent 24/7 on a VPS
Run an API-backed agent as a restartable service with private credentials, logs, health checks and basic limits.
A VPS is a good home for an AI agent that needs to run while your laptop is closed, but 24/7 availability is mostly an operations problem. The model API is only one part: the process needs restart behavior, a health endpoint, bounded permissions, spend limits and logs that do not leak prompts or keys. This guide describes a provider-neutral pattern for a Node.js or Python agent.
An API-backed agent usually needs a modest always-on server, not a GPU server. The VPS handles scheduling, tools, webhooks, queues and logs while a remote model API performs inference. A local-model agent is a different purchase: RAM and GPU VRAM become the primary constraints, and an ordinary low-cost VPS is usually the wrong machine.
Decide where inference happens before buying a VPS
API-backed agent
orOrdinary CPU VPS. Pay the model provider per request. Size the server for tools, queues, browser jobs and logs.
Local-model agent
GPU or high-memory server. Size GPU VRAM for the model and context length before comparing monthly prices.
VPS requirements
Buy for the workload, not the install command
Webhooks, queues, browser jobs, logs and a small database with useful headroom.
Local inference or many concurrent agents. Choose GPU VRAM from the model, not from the web app.
A practical API-agent architecture
Webhook / schedulerequestAgent serviceHTTPSModel APIeventsQueue + logs
Private by default
Bind the agent to localhost or a private network.
Bounded failure
Use timeouts, backoff and a maximum task duration.
Limited authority
Add tools one at a time with a dedicated Linux user.
Before touching the server
- A VPS with at least 2 vCPU and 4 GB RAM for a small API-backed agent
- A domain or private access method such as Tailscale
- An API key with a spending limit and the smallest useful permissions
- A Git repository or deployment archive for the agent code
The deployment runbook
01
Keep the agent behind a private port
Bind the application to 127.0.0.1 or an internal Docker network. Put Nginx, Caddy or a VPN in front if a browser or webhook needs to reach it. Do not make the agent's admin port public.
02
Store secrets outside the code
Use a root-readable environment file or a secret manager. Rotate the API key independently from the application deploy and never print the full environment during troubleshooting.
sudo install -m 600 /dev/null /etc/ai-agent.env
sudoedit /etc/ai-agent.env
# MODEL_API_KEY=...
# AGENT_PORT=127.0.0.1:878703
Add a health endpoint and restart policy
The health endpoint should verify the process, not make a paid model call on every probe. Run the agent with systemd or Compose so a crash does not become a silent outage.
sudo systemctl enable --now ai-agent
sudo systemctl status ai-agent
curl -fsS http://127.0.0.1:8787/health04
Control what the agent can do
Start with read-only tools, a dedicated Linux user and an allow-list of directories. Add shell, browser, email or messaging access one capability at a time. Treat every third-party skill or tool as code that needs review.
05
Monitor cost and failure modes
Track API errors, latency, queue length, token usage and restart count. Add request timeouts, retry backoff and a maximum task duration. A stuck agent should fail closed, not loop against a paid endpoint.
Common mistakes that cause real downtime
- Buying a GPU VPS for an agent that only calls an external API
- Running the agent as root or giving it unrestricted shell and filesystem access
- Putting API keys in source code, Docker images, browser JavaScript or verbose logs
- Retrying failed model calls forever without a task timeout or spending limit
- Treating a process restart policy as monitoring and never testing dependency failures
Test failure before adding more tools
Stop the process, return an invalid API response and temporarily block outbound access. A useful agent should recover predictably, record a useful error and stop spending money when its dependency is unavailable.
Before production
The process comes back after a controlled restart
API keys are absent from Git, browser responses and normal logs
The agent port is not reachable from the public internet
A deliberately invalid API response triggers a bounded retry rather than an endless loop
Next step
Keep the deployment moving
Sources and further reading
- TechRadar: self-hosting an AI agent on a VPS
- TechRadar: safely experimenting with self-hosted agents
- Ubuntu: user and privilege management
- Ubuntu: OpenSSH server configuration
Commands assume a fresh Ubuntu server. Replace domains, users, database names and provider-specific values before running them. VPS sizing is a practical starting point, not a guarantee: monitor the real workload and resize when CPU, memory, disk or network headroom becomes tight.