Running four AI agents on pocket change
A small VPS can host a household of agents.
That did not mean a small VPS could safely host every architecture those agents might need.
FR4M3W0RK's v3 snapshot targeted a four-vCPU, 8 GB machine. The gateway, n8n, Nginx Proxy Manager, and inference access were part of one deployment story. Two Telegram butlers were interactive; the writer and maker were scheduled profiles without a chat surface.
The cost story was attractive.
The security story was conditional.
The household snapshot
VPS1 — 4 vCPU, 8 GB RAM
Telegram ───────────────┐
▼
OpenClaw Gateway
├─ husband butler
├─ wife butler
├─ writer cron profile
├─ maker cron profile
└─ FR4M3W0RK-tools plugin
│
▼
n8n webhooks
│
▼
Google Calendar/Tasks/Sheets
OpenRouter supplies inference.
Nginx Proxy Manager provides the documented proxy/WAF layer.
This was the architecture as it stood in the first week of July 2026. It was not a universal production recommendation. It was a snapshot of what had survived three prior migrations and settled on a small machine.
Capability matrix
| Profile | Channel | Tools | Schedule |
|---|---|---|---|
| Husband | Telegram | Calendar, Tasks, Sheets, web, memory, cron | On demand |
| Wife | Telegram | Calendar, Tasks, Sheets, web, memory, cron | On demand; n8n credentials and strict-confirm testing still pending |
| Writer | None | Read, write, edit, memory | Daily and weekly cron |
| Maker | None | Read, write, edit, exec, memory | Daily and weekly cron |
The butlers denied exec. The writer denied exec and web search. The maker had the broadest workspace tool surface — it was the only profile with shell access — which was precisely why its sandbox status mattered.
Why the VPS was enough for some things
The machine did not need to run local model inference in the v3 design.
OpenRouter handled inference, while the VPS ran the gateway and integration services. That removed the largest performance constraint from the earlier migrations — the 48-minute response times, the 65K context windows, the 50-plus tool schemas bloating every prompt.
The model configuration named DeepSeek V4 Flash as the sole provider model at $0.09/$0.18 per million tokens. No fallback was configured. Cron retries — three attempts with 60-second, 300-second, and 900-second backoff — handled transient OpenRouter failures.
The architecture separated the cloud-intensive part from the host-intensive part.
That was an economic decision and an operational decision at the same time.
Three storage tiers
Git repository
souls, workspaces, config, scripts
source of truth for declared behavior
VPS runtime volumes
sessions, transcripts, auth state, live agent output
operational state; not identical to Git
Offsite backup
restic + rclone to encrypted Google Drive storage
useful only if restoration is tested
The repository deliberately excluded runtime diary entries and secrets. That was good source-control hygiene, but it meant a Git checkout alone could not reconstruct the complete running household.
The offsite backup ran nightly at 03:00 via host cron. It captured two Docker volumes — FR4MEW0RK_openclaw_state (agent session state, CLI device identity) and FR4MEW0RK_openclaw_agents (per-agent conversations, metadata). The workspace bind mount contents — diary entries, reflections, exec logs — were not yet included in the backup. Retention was daily for seven days, weekly for four weeks, monthly for six months, yearly for two years.
Backups preserved more state than Git, but an encrypted backup that had never been restored was a recovery intention, not recovery evidence.
The Compose boundary
The gateway service was packaged in Docker. It mounted the repository configuration read-only, workspaces read-write, two named state volumes, and an optional deployment environment file.
docker-compose.yml volumes:
./openclaw-config:/etc/openclaw:ro — config (read-only)
./workspaces:/var/lib/openclaw/workspaces — agent workspaces (read-write)
openclaw_state:/var/lib/openclaw/.openclaw — gateway state
openclaw_agents:/var/lib/openclaw/agents — agent runtime data
./deploy/.env — secrets (optional, mode 0600)
The gateway ran as root inside the container. It sat on a shared Docker network (proxy-net) alongside n8n, Nginx Proxy Manager, and WireGuard. The gateway port (18789) was bound to loopback only — not exposed to the public internet directly.
The maker had exec access inside the gateway container. The sandbox was set to mode: "off" globally. There was no per-agent sandbox override. The maker could execute shell commands within the gateway container's filesystem and environment. The intended Docker socket mount for a proper sandbox had not yet been added — at this snapshot, the maker's exec ran inside the gateway container without a containerized sandbox of its own.
That combination — exec access, no sandbox, shared network, root process — materially changed what "four agents on one VPS" meant. It was not a hypothetical risk. It was the reviewed, effective configuration.
Cost model without false precision
monthly operating cost
= VPS rental
+ model inference usage
+ backup storage/transfer
+ domain/proxy/integration overhead
+ operator time
The project treated the small VPS, cloud inference, encrypted backup, and n8n/Google integration as separate cost lines. A precise-looking total would have been less honest than a range with evidence attached.
The interesting result was not that cloud inference could be cheap. It was that cost was produced by architecture: context size, heartbeat frequency, retries, and scheduled turns all affected the bill. The heartbeat incident had demonstrated that a single configuration default could multiply cost by orders of magnitude, regardless of the model price.
What "pocket change" hides
The low monthly infrastructure price did not include:
- debugging version and schema changes;
- recovering device scopes and cron registration;
- configuring Google OAuth credentials;
- testing wife onboarding and strict confirmation;
- verifying n8n workflow activation;
- fixing container timezone alignment;
- reviewing Docker mounts and sandbox drift;
- or determining whether a backup could actually be restored.
The operator was part of the architecture.
Small infrastructure did not mean small operations.
Where things stood
By July 8, the v3 architecture was running on VPS1.
Four agents shared one OpenClaw gateway. The butlers responded to Telegram messages on demand. The writer ran daily at 02:00 and weekly on Sundays at 03:00. The maker ran daily at 04:00 and weekly on Sundays at 05:00. All cron jobs used --tz "Asia/Shanghai" and --no-deliver.
DeepSeek V4 Flash handled inference through OpenRouter. The heartbeat blocks were gone. The n8n webhook bridge connected the native plugin to Google Calendar, Tasks, and Sheets — the husband-side workflows had real credentials, the wife-side workflows still contained unresolved placeholders.
The gateway ran as root on a shared network. The sandbox was off. The maker had exec access. The Docker socket was not yet mounted, but the container had no filesystem isolation preventing the maker from writing anywhere the gateway process could reach.
The offsite backup captured Docker volumes but not the workspace bind mount. The doctor script checked containers, networks, plugins, cron jobs, secrets, token budget, soul round-trip, and backup age — but could not verify that a backup would actually restore.
Three migrations had bought a system that cost almost nothing to run and was not yet proven safe to operate.