When you hear “hundreds of microsites,” you probably imagine a mess of DNS records, half‑deprecated repos, and a Google Sheet that only one person understands.

MiniSite Host was built to make that mess boringly predictable. In this post, we’ll walk through how we use Cloudflare R2, D1, and Workers to host a lot of minisites without losing sleep.

The core idea: one worker, many minisites

Instead of spinning up new infrastructure for every minisite, we treat minisites as data, not projects.

At a high level:

• Static files for each minisite live in their own folder in Cloudflare R2.
• Metadata (owner, slug, quotas, flags) lives in Cloudflare D1.
• A single Cloudflare Worker sits in front of everything and decides which minisite to serve based on the incoming request.

Because all routing logic lives in one place, we can add features—password protection, usage tracking, custom domains—without cloning infrastructure.

What happens on each request

When a visitor hits a minisite URL like:

https://yourbrand.minisite.host/launch/demo

our Worker roughly does the following:

1. Look up the minisite in D1 using the path and host.
2. Check quota and access rules (for example, password gate or internal‑only flag).
3. Fetch the static assets from the right folder in R2.
4. Stream the response back through Cloudflare’s edge, so it stays fast around the world.

This design is intentionally boring. We lean on Cloudflare’s global network instead of building our own CDN or edge cache.

Why this matters for your team

From a user’s perspective, all of this complexity collapses into a simple promise:

• You upload a folder or zip.
• You pick a slug.
• Your minisite is live on a fast, SSL‑enabled URL in under two minutes.

You don’t have to think about buckets, workers, or database schemas. But if you care about reliability and performance, it’s nice to know there’s a clean architecture behind the scenes.

Where we’re going next

Because everything runs through a single Worker and a shared schema, we can add platform‑level capabilities without breaking existing sites:

• Org‑level quotas and billing based on D1 data.
• Team roles and impersonation for support and success.
• Feature flags powered by KV or Durable Objects for gradual rollouts.

MiniSite Host will keep evolving, but this core pattern—one simple edge entry point, lots of focused minisites—is here to stay.

If you’d like to dig deeper into implementation details, we’ll share more architecture notes and migration guides in future posts.