Zero DevOps E-commerce with Cloudflare Workers & Turborepo

Tired of maintaining expensive Kubernetes clusters, fine-tuning Auto-scaling groups on AWS, or wiring together complex CI/CD pipelines just to keep an e-commerce store alive? Welcome to the Zero DevOps era.

In this post, we dissect Aura Store — a production-grade Cloudflare Workers E-commerce platform built entirely on Edge infrastructure, powered by a Turborepo Monorepo. Everything you see below is drawn directly from the running codebase.

1. Turborepo Monorepo Architecture in Practice

Answer-first: Turborepo splits the e-commerce system into four independent apps — storefront-ui, admin-ui, public-api, and admin-api — and two shared packages: database and contract. This separation maximises build speed via Turborepo’s task graph cache and enforces a hard security boundary between the public-facing layer and internal tooling.

Merging an Admin API and a Public API into a single backend is an invitation for privilege escalation bugs. Aura Store keeps them strictly apart:

• apps/storefront-ui: Customer-facing storefront (Next.js 15+) — deployed to Cloudflare Pages for Edge rendering.
• apps/public-api: Cloudflare Worker that serves the storefront and third-party integrations.
• apps/admin-api: A separate Cloudflare Worker with strict RBAC middleware. Unreachable from the public internet path.
• packages/contract: Zod schemas and OpenAPI specs — the single source of truth for all API payloads.
• packages/database: Drizzle ORM schema and migrations for Cloudflare D1.

Because both apps and packages share the same Turborepo workspace, a schema change in packages/contract or packages/database propagates to all consumers at build time — no manual version bumping required.

2. Cloudflare D1 & Drizzle ORM: Relational Data at the Edge

Answer-first: Cloudflare D1 (SQLite Edge) paired with Drizzle ORM delivers globally distributed, type-safe relational queries with no connection pools to manage. D1 reads data from the edge node closest to the user — eliminating the round-trip to a centralised origin database.

Handling relational data at the Edge was the biggest unsolved problem of Serverless architecture. Cloudflare D1 changes that. The wrangler.toml configuration for public-api illustrates just how little setup is required:

name = "public-api-worker"
compatibility_date = "2024-06-05"
compatibility_flags = ["nodejs_compat"]

[[d1_databases]]
binding = "DB"
database_name = "ecommerce-db"
database_id = "YOUR_D1_DATABASE_ID"      # from: wrangler d1 create <db-name>
  preview_database_id = "local"        # local SQLite when running wrangler dev
  migrations_dir = "../../packages/database/migrations"

There is no connection string to protect, no connection pool to tune, and no idle timeout to worry about. The Worker receives the DB binding at runtime, and Drizzle ORM provides full type-safety from the database schema in packages/database all the way up through the API response.

Beyond D1, the same wrangler.toml wires up the rest of the Cloudflare ecosystem in a few additional lines:

[[kv_namespaces]]
binding = "CACHE_KV"
  id     = "YOUR_KV_NAMESPACE_ID"   # from: wrangler kv namespace create CACHE_KV

[[r2_buckets]]
binding     = "PRODUCTS_R2"
bucket_name = "e-commerce"

[[queues.consumers]]
queue             = "ecommerce-events-prod"
max_batch_size    = 10
max_retries       = 3
dead_letter_queue = "ecommerce-events-dlq"

KV for caching, R2 for object storage, and Queues for async event processing — all bound to the Worker with zero extra infrastructure provisioned.

3. The Architecture Highlight: Automated Mobile SDK Generation

Answer-first: Instead of manually maintaining HTTP clients for Flutter and iOS, the system auto-generates Dart and Swift SDKs from Zod schemas on every merge to main. Any change to packages/contract triggers a GitHub Actions pipeline that compiles OpenAPI JSON and pushes fresh SDK code — no human handoff required.

This is the sharpest edge of Aura Store’s architecture, and one that almost no Cloudflare tutorial covers. API contracts are defined once as Zod schemas in packages/contract. When a PR merges, the pipeline runs:

# Source: .github/workflows/openapi-sdk.yml
- name: Generate OpenAPI JSON Spec
  run: pnpm --filter @ecommerce/contract build:openapi

- name: Generate Dart SDK (Flutter)
  run: |
    openapi-generator-cli generate \
      -i ./packages/contract/openapi.json \
      -g dart \
      -o ./sdks/dart \
      --additional-properties=pubName=aura_api_sdk,pubVersion=1.0.0

- name: Generate Swift SDK (iOS)
  run: |
    openapi-generator-cli generate \
      -i ./packages/contract/openapi.json \
      -g swift5 \
      -o ./sdks/swift \
      --additional-properties=projectName=AuraApiSDK

- name: Create Pull Request
  uses: peter-evans/create-pull-request@v6
  with:
    commit-message: 'chore: auto-generate API SDKs from latest contracts'
    branch: 'auto/sdk-update'

The pipeline opens a PR with the regenerated SDKs. Mobile teams merge it and ship — no reading changelogs, no manually diffing JSON payloads, no type mismatch bugs at runtime.

4. Zero DevOps Deployment: No CI/CD Pipelines to Maintain

Answer-first: Zero DevOps means pushing to main and walking away. Cloudflare’s native GitHub integration detects the push, runs the build for each app in the workspace, and deploys globally across 300+ cities. No Kubernetes manifests, no Helm charts, no Jenkins job to babysit.

Each app in the Turborepo maps to a separate Cloudflare project:

Secrets are managed without .env files in CI. Set them once via the Wrangler CLI:

wrangler secret put STRIPE_WEBHOOK_SECRET
wrangler secret put JWT_SECRET

For local Stripe Webhook testing, forward events to the running Worker dev server:

stripe listen --forward-to localhost:8787/api/webhooks/stripe

The Stripe CLI prints a STRIPE_WEBHOOK_SECRET value; paste it into apps/public-api/.dev.vars. The dev environment mirrors production exactly — same code path, same Worker runtime, same D1 schema.

5. FAQ: Cloudflare E-commerce Architecture

What is a Zero DevOps architecture?

Zero DevOps is a model where engineers spend 100% of their time writing product code rather than operating servers. With the Cloudflare ecosystem, there is no OS to patch, no scaling group to tune, and no load balancer certificate to rotate. The platform handles availability, global distribution, and DDoS mitigation automatically.

Why use Cloudflare Workers instead of AWS Lambda?

The fundamental difference is the runtime model. AWS Lambda runs inside a lightweight container that must cold-start — a virtualisation layer that adds 100ms–500ms on the first request. Cloudflare Workers run on V8 isolates: the same engine that powers Chrome, with near-zero cold start overhead. On a globally distributed network of 300+ cities, most users receive a sub-millisecond response from an edge node physically close to them — without any geo-routing configuration.

How do you handle relational data at the Edge?

Instead of routing every query back to a centralised RDS instance in us-east-1, use Cloudflare D1. D1 is a globally distributed SQL database built on SQLite. Drizzle ORM wraps D1 with a fully type-safe query builder, so your schema and queries are validated at compile time — not at runtime in production.

Further reading: Cloudflare D1 official docs · Turborepo documentation · Dapr Pub/Sub for event-driven microservices

Serverless Edge Architecture is not the future. It is the present. Explore more modern architecture patterns in the System Design Series and browse all Cloudflare and DevOps posts on the blog.

📬 Get the weekly Tech Radar — no spam, only signal: Subscribe here.