Code · May 4, 2026

Cloudflare Workers in 2026: build and deploy a real API with KV, D1, and R2

Q: Is D1 ACID?

Yes — single-region writes are fully ACID. Reads from replicas are eventually consistent within ~1s.

Q: Can I run cron jobs on Workers?

Yes, via Cron Triggers. Up to 5 schedules per worker, can execute up to 30s.

Q: How do I monitor Workers?

Built-in observability dashboard. Logpush for full logs to R2/S3. Sentry integration is one-click.

Q: Is Hono required?

No, but recommended. The router is fast, types are good, and most Workers tutorials assume it. Vanilla Workers + ittr-router is a viable lighter option.

A walkthrough that builds a real API on Cloudflare Workers in 2026 — using Wrangler 4, KV for caching, D1 for the database, and R2 for files.

By ByteLedger Team

Cloudflare Workers matured into a credible API platform between 2024 and 2026. D1 (SQLite at the edge) hit GA, R2 became cheaper than S3 for most use cases, and Wrangler 4 fixed the developer experience that was rough through 2023. The result: indie devs and startups can host serious APIs for $0-30/month with sub-50ms global latency.

What changed in 2026

D1 GA in early 2025 — stable, with read replicas across regions.
Wrangler 4 with proper TypeScript types, hot reload, and remote bindings in local dev.
Smart Placement automatically co-locates Workers near their data.
Workers AI runs Llama and other models inside Workers — fast, cheap inference for many tasks.

The minimal API

Using Hono, the lightweight framework most Workers projects pick:

import { Hono } from 'hono'

type Bindings = {
  DB: D1Database
  CACHE: KVNamespace
  FILES: R2Bucket
}

const app = new Hono<{ Bindings: Bindings }>()

app.get('/posts', async (c) => {
  const cached = await c.env.CACHE.get('posts:all', 'json')
  if (cached) return c.json(cached)

  const { results } = await c.env.DB.prepare('SELECT * FROM posts ORDER BY created_at DESC LIMIT 50').all()
  await c.env.CACHE.put('posts:all', JSON.stringify(results), { expirationTtl: 60 })
  return c.json(results)
})

app.post('/files', async (c) => {
  const body = await c.req.parseBody()
  const file = body.file as File
  await c.env.FILES.put(`uploads/${crypto.randomUUID()}-${file.name}`, file.stream())
  return c.json({ ok: true })
})

export default app

Wrangler 4 setup

# wrangler.toml
name = "my-api"
main = "src/index.ts"
compatibility_date = "2026-04-01"

[[d1_databases]]
binding = "DB"
database_name = "my-db"
database_id = "..." 

[[kv_namespaces]]
binding = "CACHE"
id = "..."

[[r2_buckets]]
binding = "FILES"
bucket_name = "my-uploads"

Then:

wrangler dev — local dev with real bindings (D1 spins up locally, KV works, R2 writes to a local stub).
wrangler d1 migrations apply my-db — run migration files.
wrangler deploy — push to all 300+ edge locations.

That's the entire deploy story. No Docker, no Kubernetes, no scaling configuration.

D1 production realities

D1 is SQLite at the edge with read replicas. Strengths: blazing-fast reads from any region, cheap, no connection pooling required. Limits: writes go through one primary; if you have a write-heavy workload (think: CRM with 100k+ writes/day), D1 may not fit. Database size cap is 10GB on the standard tier (50GB on enterprise). For typical content sites, indie SaaS, and dashboards, D1 is more than enough.

When NOT to use Workers

Heavy compute workloads. 30s CPU limit per request. Use Workers for orchestration, push compute to dedicated services.

WebSocket-heavy apps with persistent state. Possible via Durable Objects but adds complexity. Sometimes simpler on a server.

Apps requiring direct Postgres. D1 is SQLite. If you need Postgres-specific features, look at Hyperdrive (Workers + remote Postgres) or skip Workers entirely.

Existing Node.js apps with deep dependencies. Workers' V8 isolate environment doesn't run all Node packages.

Comparison: Workers vs alternatives

Platform	Cold start	Free tier	Best for
Cloudflare Workers	<5ms	100k req/day	Edge APIs, content sites
Vercel Functions	200-1000ms	Limited	Next.js apps
AWS Lambda	100-2000ms	1M req/mo	Mature AWS shops
Deno Deploy	50-200ms	1M req/mo	Deno-first projects
Fly Machines	N/A (always-on)	Limited	Stateful workloads

Common mistakes to avoid

Skipping local dev with wrangler dev. Test against real bindings before pushing.

Using KV as a database. KV is eventual-consistent, write-throttled. It's a cache, not storage.

Forgetting to set TTL on KV writes. Cached forever by default — stale data follows.

Putting secrets in wrangler.toml. Use wrangler secret put instead.

Building monolithic Worker files. Routes scattered across many files compose better; the bundler handles it.

FAQ

Is D1 ACID? Yes — single-region writes are fully ACID. Reads from replicas are eventually consistent within ~1s.

Can I run cron jobs on Workers? Yes, via Cron Triggers. Up to 5 schedules per worker, can execute up to 30s.

How do I monitor Workers? Built-in observability dashboard. Logpush for full logs to R2/S3. Sentry integration is one-click.

Is Hono required? No, but recommended. The router is fast, types are good, and most Workers tutorials assume it. Vanilla Workers + ittr-router is a viable lighter option.