AWS and Vercel will bleed you dry with unpredictable compute costs. I deploy 24/7 autonomous Python agents on a $5 Hetzner VPS instead.
Serverless platforms like Vercel and AWS Lambda fail at one thing: keeping agents alive. A serverless function dies after 60 seconds. An agent needs permanent uptime to monitor webhooks, run cron jobs, and execute long reasoning loops. This is why business AI agents need dedicated infrastructure.
I watched a client deploy an agent on AWS Lambda. The bill hit $400 in one month.
We rebuilt it on a Hetzner CX22. Same workload. Same model calls. Infrastructure cost dropped to 5 per month. The agent got faster because it never cold starts.
The Bare-Metal Architecture
Human capability multiplication runs on dedicated, bare-metal servers. A Hetzner VPS gives you root Linux access, predictable $5/month billing, and zero timeouts. This is the infrastructure layer for agentic AI implementation.
You get a full Linux box. No cold starts. No function limits. No surprise invoices.
I standardize on Hetzner CX22 or CPX21. Two vCPUs, 4 GB RAM, 40 GB SSD. That runs a Python agent, a local database, a task queue, and Nginx without breaking a sweat. Ubuntu 24.04. SSH keys only. Firewall locked to ports 22, 80, and 443.
The agent stays boring on purpose. One long running Python process. A SQLite file for short term memory. A folder of JSON state files for open workflows. The full memory layout lives in my personal AI agent infrastructure notes.
Root access matters more than people expect. I pin packages, set process limits, write cron entries, and pull raw logs without asking a hosting platform for permission.
Deploying the Systemd Service
I skip Docker and messy PM2 scripts. I write a native Linux systemd service file.
[Unit]
Description=Autonomous Legal Agent
After=network.target
[Service]
User=root
WorkingDirectory=/root/agent-core
ExecStart=/usr/bin/python3 /root/agent-core/main.py
Restart=always
RestartSec=5
Environment=ANTHROPIC_API_KEY=sk-ant-...
[Install]
WantedBy=multi-user.targetSave this to /etc/systemd/system/agent.service, run systemctl enable agent, and your agent becomes permanently embedded in the OS. If it crashes, Linux restarts it in 5 seconds.
Key insight: systemd makes your agent indestructible. It runs as part of the operating system, not on top of it. For production examples, see the case studies.
The Loop Inside main.py
systemd keeps the process alive. The loop inside the process does the real work.
My agents run three timers at once.
- A webhook listener on port 8080 behind Nginx. Make.com and Stripe push events straight into it.
- A poll every 60 seconds for queued jobs that need retries.
- A nightly cron at 02:00 for batch work: document sweeps, billing checks, memory cleanup.
Every event lands in a SQLite table before any model call happens. That one file is my audit log and my retry queue. When the API returns a 429, the worker sleeps and requeues the job. Nothing falls through.
I declare every tool the agent can call in a small JSON schema. The agent picks a tool, the host executes it, the result goes back in the log. Same idea as my tool-calling architecture writeup. Permissions stay explicit and reversible.
The Real Monthly Bill
The stack I run for most client agents.
- Hetzner CX22: $5/month
- Backups and snapshots: $1/month
- Domain and DNS: $1/month
- Model calls at moderate volume: $20 to $60/month
Total stays under $70 a month including model spend. The Lambda version of the same agent cost $400 and still timed out during long document runs.
Failure Handling
Agents fail. The difference is how fast you notice.
systemd restarts dead processes. A simple health file records the last successful heartbeat. A cron job checks that file every 5 minutes and pings Slack when it goes stale. That is the whole monitoring stack. A 40 line Python script does the job.
I write three fields into every log line: timestamp, event name, and the workflow ID that spawned it. When a client says the agent missed a task, I grep one file and have the answer in 30 seconds. That habit alone has saved me more hours than any dashboard ever did.
I also keep one rule: never store credentials in the repo. The service file reads keys from an environment file owned by root. Rotate the key, restart the service, done.
The agent this box runs is a CLI, and the whole build sits in how to build your own AI CLI. Want me to deploy this for your business? Download the Blueprint or AI Workflow Repair Intake. If you are still mapping the agent layer first, start with agentic AI implementation.
| Operational layer | Fragile default | Production architecture |
|---|---|---|
| Process design | Automating a broken manual habit as-is | Mapping the data contract and failure modes before writing code |
| Human oversight | Either 100% manual or unguarded autopilot | Autonomous execution on routine cases with approval gates on exceptions |
| Data custody | Operations locked inside third-party SaaS | Code, prompts, logs, and API keys owned inside your accounts |
| Failure recovery | Silent drops when an upstream API changes | Schema validation, retries, and operator alerts on every break |
FAQ
What is the first step to implementing deploying autonomous ai agents on hetzner vps?
Start by mapping the single workflow that loses the most hours each week, defining the exact input and output data contract, and placing human approval gates before writing code.
How do you measure whether an AI workflow is working in production?
Track time-to-completion, exception queue rate, duplicate or failed writes, and the hours returned to operators each week compared to the manual baseline.
Can our team run the system after the engagement ends?
Yes. Every build includes architecture documentation, alerting, and live operator training so your team owns and runs the system without an ongoing retainer.