How to Deploy AI Agents on Cloudflare Workers: A Solo Founder's 2026 Guide

To deploy an AI agent on Cloudflare Workers, use the Agents SDK (npm i agents), define a class that extends Agent so each instance runs as a stateful Durable Object with its own SQLite storage and built-in scheduling, then ship it with wrangler deploy — no servers, no external database, no separate cron service. That's the whole shape of it. The parts that trip up a solo founder aren't the deploy command; they're the CPU-time limits, where state lives, and which actions you let the agent take on its own. I run exactly this stack under 1mn — autonomous loops deployed on Workers that do the recurring work of my SaaS, with a human gate on anything irreversible.

This is the guide I wish I'd had the first time I pointed an agent at production.

What "an AI agent on Cloudflare Workers" actually means

An agent on Workers is a long-lived, stateful object that calls a model, remembers what happened, and can schedule its own future work — not a stateless function that forgets everything the moment it returns. The difference is the runtime underneath it — which is the whole reason AI agents need infrastructure built differently from traditional request-response software. This guide is the Cloudflare-specific cut of that idea.

According to Cloudflare's Agents documentation, agents built with the Agents SDK "run on top of Durable Objects — stateful micro-servers that can scale to tens of millions." Each agent instance is a Durable Object with its own embedded SQLite database, so state persists automatically across requests and hibernation cycles without you provisioning anything.

The economics are the quiet win for a solo founder. Per the official cloudflare/agents repo, agents "hibernate when idle and wake on demand — you can run millions of them, one per user or per session, each costs nothing when inactive." One agent per customer stops being a scaling nightmare and becomes the default.

Step 1: Scaffold the agent

The fastest path is the official starter, which deploys in three commands. From Cloudflare's docs:

npm create cloudflare@latest -- --template cloudflare/agents-starter
cd agents-starter
npm run deploy

The starter ships with streaming AI chat, server-side and client-side tools, human-in-the-loop approval, and task scheduling — and it uses Workers AI by default, so no API keys are required to see it run. You can swap in OpenAI, Anthropic, or Gemini later.

If you already have a Workers project, skip the template and add the SDK directly:

npm i agents

Step 2: Define a stateful agent

Every agent is a class that extends Agent, and that single decision gives you persistent state, SQL storage, and scheduling for free. A minimal shape looks like this:

import { Agent } from "agents";

export class ResearchAgent extends Agent<Env, State> {
  async ask(question: string) {
    // this.setState(...)  — durable, auto-synced state
    // this.sql`...`       — per-instance SQLite
    // this.schedule(...)  — built-in future work
    const answer = await this.env.AI.run(/* model */);
    this.sql`INSERT INTO log (q, a) VALUES (${question}, ${answer})`;
    return answer;
  }
}

Three built-ins do the heavy lifting, per the Agents SDK reference:

• this.setState — durable state that survives restarts and syncs to connected clients automatically.
• this.sql — a per-instance SQLite database, zero-latency, no external DB to wire up.
• this.schedule(when, method, payload) — future work where when is a delay in seconds, a Date, or a cron expression. The scheduler lives inside the instance; no external cron service needed.

Step 3: Schedule the recurring work

For work that runs on a clock, you have two options, and picking the wrong one is the most common early mistake.

Inside an agent, use this.schedule('daily at 5pm', 'runDigest') — this is best for per-user, per-instance jobs (a daily digest for this customer). At the Worker level, use a Cron Trigger with a scheduled() handler for account-wide jobs.

Cron Triggers come with real limits worth knowing before you architect around them. According to the runhooks.app 2026 reference and Cloudflare's own docs:

Constraint	Value (2026)
Cron Triggers per Worker	3 (Free) / 5 (Paid)
Minimum interval	1 minute (* * * * *)
Automatic retries on failure	None
Built-in failure alerts	None
Timezone	UTC only

The one that bites: a failed scheduled run is simply lost until the next tick — no retry, no alert. If the job matters, log its outcome somewhere you actually watch.

Step 4: Use Workflows for anything that must not half-finish

For multi-step jobs that can't be left half-done — a research task, a billing run, a deploy pipeline — wrap the steps in a Cloudflare Workflow instead of a plain function. Workflows give you durable execution.

Per Cloudflare's Workflows guide, step.do(name, callback) "executes code and persists the result. If the Workflow is interrupted, it resumes from the last successful step." That's the difference between an agent that crashes and restarts from zero, and one that picks up exactly where it left off. The AgentWorkflow class extends Workflows with bidirectional agent communication, so the workflow can report progress back to the agent (and to any connected WebSocket clients) as it runs.

The limits that actually bite

The hard part of running agents on Workers isn't writing them — it's staying inside the CPU-time envelope. These are the numbers I keep taped to my monitor, from Cloudflare's limits and pricing docs (2026):

Handler	CPU-time limit	Best for
fetch() (HTTP)	30s default, up to 5 min via cpu_ms	User-facing requests
scheduled() cron, < 1h interval	30 seconds	Frequent periodic jobs
scheduled() cron, ≥ 1h interval	15 minutes	Heavy hourly/daily batches
Queue consumer	15 min wall time	On-demand heavy processing

Two facts save you a lot of debugging. First, CPU time only counts code execution — waiting on fetch(), KV, or a model call does not count against it, per Cloudflare's limits docs, so an agent that spends most of its time awaiting an LLM has more headroom than the raw number suggests. Second, cron granularity bottoms out at one minute and each invocation is capped at 1,000 outbound subrequests — if your agent fans out to hundreds of API calls, that ceiling arrives before the time limit does.

If you need genuinely long, on-demand compute, push it to a Queue consumer (15-minute wall time) rather than trying to stretch an HTTP request.

How I run this without babysitting it — 1mn

I don't hand-deploy and hand-watch each agent loop anymore; I let 1mn run them and I review the output. 1mn is an autonomous agent that runs the product, marketing, and support loops of a one-person SaaS on a schedule — deployed natively on the Cloudflare stack (Workers, Durable Objects, Queues, D1, R2, cron triggers), which is exactly the architecture in this guide.

The part that makes it safe to leave running is the human gate: reversible work (dogfooding the product, drafting content, monitoring ad spend) runs unattended on a cron, but anything irreversible — deploying code, spending money, touching a customer — stops and waits for my approval. The reversible loop runs on its own; the risky call stays mine. It's built for the solo serverless stack, so there's no infrastructure to stand up first. Start the 14-day free trial (no per-seat pricing, cancel anytime) and connect a Cloudflare/Vercel + GitHub project to activate the loops.

If you're deciding which agent actions to let run unattended versus gate, that's its own decision — I wrote it up in which AI agent actions need a human gate. And if you're weighing the running cost of always-on loops, see what autonomous AI agents cost to run in 2026. This piece is part of how I run a solo SaaS on AI agents.

A production checklist before you point traffic at it

Cloudflare's quickstarts leave a few things implicit. A July 2026 production guide from KSPL Academy spells out the ones that matter, and they match what burned me:

• Enable Workers observability in config first, then confirm logs actually appear for a real request.
• Propagate a request ID through the Worker, the Durable Object, queue messages, and every model call, so you can trace one agent run end to end.
• Track per-agent model spend through AI Gateway or your provider's billing export — model cost, not compute, is usually the real bill.
• Put large artifacts in R2, not Durable Object SQLite — DO storage is for state, not blobs.
• Scope one Durable Object to one natural owner (user, tenant, room, or workflow), and load-test the busiest one, because a single Durable Object is intentionally single-threaded for consistency.

Do these before launch, not after your first incident.

FAQ

What's the fastest way to deploy an AI agent on Cloudflare Workers? Run npm create cloudflare@latest -- --template cloudflare/agents-starter, then npm run deploy. The starter uses Workers AI by default (no API key needed) and ships with chat, tools, human-in-the-loop approval, and scheduling, so you have a running agent in three commands and can customize from there.

Do I need Durable Objects to run an agent on Workers? Yes, for a stateful agent. Each agent instance in the Agents SDK is a Durable Object with its own embedded SQLite database, which is what lets state persist automatically across requests and hibernation. A stateless Worker function can call a model, but it can't remember anything between invocations or schedule its own future work.

How long can a Cloudflare Worker agent run? It depends on the trigger. An HTTP request allows up to 5 minutes of CPU time (30 seconds by default, raised via cpu_ms); a cron-triggered scheduled() handler gets 30 seconds if it runs more often than hourly and up to 15 minutes if the interval is an hour or more; Queue consumers get 15 minutes of wall time. Crucially, time spent awaiting fetch() or model calls doesn't count toward CPU time.

How much does it cost to run agents on Cloudflare Workers? The Workers Free plan includes 100,000 requests/day with 10ms CPU per invocation; the Standard plan includes 10 million requests and 30 million CPU-milliseconds per month, then $0.30 per additional million requests and $0.02 per additional million CPU-ms, per Cloudflare's 2026 pricing. Idle agents hibernate and cost nothing, so per-user instances stay cheap. Your larger bill is usually model/LLM spend, which is why tracking it per agent matters.

Can a Cloudflare agent schedule its own tasks without an external cron? Yes. The Agents SDK provides this.schedule(when, method, payload) where when accepts a delay in seconds, a Date, or a cron expression — the scheduler runs inside the Durable Object itself. For account-wide jobs you can also use Worker-level Cron Triggers, but note they cap at 3–5 per Worker, run no more than once a minute, and don't retry on failure.