Cloudflare Pages vs Workers for an email app: which to host on

You're about to deploy an email app on Cloudflare and the docs offer two front doors: Pages and Workers. Pick wrong and you'll discover halfway through that your background sender can't even run.

Both Pages and Workers can serve a web app on Cloudflare's edge, run server-side code, and bind to D1, R2, and KV. For a generic CRUD app the choice is mostly taste. For an email app it is not taste, because email has a specific shape: things arrive, things get queued, things run on a schedule, and a human looks at a UI in between. That shape lines up cleanly with one of these products and awkwardly with the other.

This is a TOFU decision guide. It lays out what each product actually does, where the lines are as of mid-2026, and why an email stack lands on Workers. If you just want the answer: host it as a Worker with static assets. The rest explains why so you can defend the choice.

What is the actual difference between Cloudflare Pages and Workers?

Pages is a static-site host with an optional serverless function layer; Workers is a general-purpose edge runtime that can also serve static files. They share the same underlying runtime (workerd) and the same bindings (D1, R2, KV, Queues), so the difference is not raw capability, it's which entry points each one exposes. Those bindings are the same building blocks covered in the Cloudflare primitives every email stack is built on, so the question here is purely which product surfaces the handlers that wire them together.

A Worker is a single script that exports handlers. The runtime calls whichever handler matches the event:

export default {
  async fetch(req, env, ctx) { /* HTTP requests */ },
  async queue(batch, env, ctx) { /* Queue consumer */ },
  async scheduled(event, env, ctx) { /* Cron Triggers */ },
  async email(message, env, ctx) { /* inbound mail via Email Routing */ },
};

A Pages project is built around a static asset directory plus Pages Functions: files under functions/ that map to routes and run on HTTP requests. Pages Functions are, under the hood, a Worker that Cloudflare generates for you, but the project model only surfaces the request path. There is no place in a Pages project to export a queue, scheduled, or email handler. That single missing surface is the whole story for email.

Can Cloudflare Pages Functions run a Queue consumer or a cron job?

No. Pages Functions only run in response to incoming HTTP requests. They cannot register a Queue consumer, a Cron Trigger, or the inbound email() handler. If your app needs work to happen because a queue message arrived, because a schedule fired, or because mail came in, Pages Functions structurally cannot host that work.

This trips people up because Pages Functions can be a Queue producer. You can enqueue a message from a Pages Function just fine: producing is a binding call, it happens inside a request. What you cannot do is consume that queue from the same Pages project, because consuming is a separate event the runtime delivers outside any request. You'd have to deploy a second deployment, a standalone Worker, to drain the queue. At that point you're running a Worker anyway, plus a Pages project, plus the coordination between them.

Here is the table that matters for an email app:

Handler / trigger	Worker	Pages Functions
HTTP requests (fetch)	Yes	Yes
Static asset serving	Yes (assets binding)	Yes (native)
Queue producer	Yes	Yes
Queue consumer (queue)	Yes	No
Cron Triggers (scheduled)	Yes	No
Inbound email (email)	Yes	No
D1 / R2 / KV bindings	Yes	Yes

The three "No" rows are exactly the load-bearing pieces of an email stack.

Why does an email app need the handlers Pages can't run?

An email app needs Queue consumers for reliable sending, Cron Triggers for scheduled sends, and the email() handler for receiving mail. Strip those out and you're left with fire-and-forget sends that drop under load and an app that can't receive anything. Walk through what each piece does:

Sending reliably needs a Queue consumer. You cannot send mail synchronously inside the request that triggered it. A signup handler that blocks on a delivery API will time out under load, and if the delivery call fails you have nowhere to retry it. The correct pattern is: the request enqueues a send job and returns immediately; a Queue consumer drains the queue, performs the delivery, signs with DKIM, and retries with backoff on failure. The consumer is a queue() handler. Pages can't host it. (We dig into this pattern in sending email reliably with Cloudflare Queues, and the broader set of patterns is in Cloudflare Queues patterns for reliable email sending.)

Scheduled sends need Cron Triggers. A daily digest, a drip sequence, a "we noticed you didn't finish signup" nudge: all of these fire on a schedule, not on a request. That's a scheduled() handler wired to a Cron Trigger. Pages has no equivalent. The full menu of recurring jobs this unlocks is in the ways Cloudflare Cron Triggers can run your email.

Receiving mail needs the email() handler. If your app does anything with inbound mail, replies into a thread, a support inbox, OTP extraction, inbound webhooks, it goes through Cloudflare Email Routing, which delivers messages to a Worker's email() handler. There is no Pages route that receives an inbound message.

So the moment your email app graduates from "fire one transactional email and hope" to "queue sends, schedule campaigns, and receive replies," you need all three Worker-only handlers. An email app that does the full job is a Worker by definition.

Do you lose static hosting if you skip Pages?

No. This was the historical reason to reach for Pages, and it's no longer true. Workers support static assets natively: you point the assets binding at a build output directory and Cloudflare serves those files straight from edge cache, without invoking your Worker code or billing you for the request.

{
  "name": "my-email-app",
  "main": "src/index.ts",
  "compatibility_date": "2026-06-01",
  "assets": {
    "directory": "./dist",
    "binding": "ASSETS",
  },
}

With that block, a request to /app/inbox for a built file is served as a static asset directly; a request that doesn't match a file falls through to your fetch() handler (your API, your SSR, whatever). You get Pages-style static hosting and a full Worker, in one deployment, with one wrangler deploy. The old "Pages for the frontend, Workers for the backend" split is now just one Worker.

A concrete shape for an email app:

export default {
  // Webmail UI + API. Static assets are served before this runs;
  // this handles API routes and anything that isn't a static file.
  async fetch(req, env, ctx) {
    const url = new URL(req.url);
    if (url.pathname.startsWith("/api/")) return handleApi(req, env);
    return env.ASSETS.fetch(req); // SPA fallback
  },

  // Background sender: drains the send queue with retries.
  async queue(batch, env, ctx) {
    for (const msg of batch.messages) await deliver(msg.body, env);
  },

  // Scheduled campaigns and digests.
  async scheduled(event, env, ctx) {
    await runDueCampaigns(env);
  },

  // Inbound mail from Email Routing.
  async email(message, env, ctx) {
    await ingestInbound(message, env);
  },
};

One file, one deployment, every surface an email app needs. Try to express that as a Pages project and you immediately split into multiple deployments.

When is Pages still the right call?

Pages is the right call when your app is purely static or HTTP-only and you value the Pages workflow. If you're building a marketing site, docs, a blog, or a frontend whose only server-side work happens inside requests (a contact form that enqueues to a queue someone else drains, say), Pages is excellent: Git-connected deploys, preview URLs per pull request, and zero config for the static layer.

The honest summary: Pages optimizes for "static site with some request-time functions." Workers optimizes for "an app that also needs background and event handlers." Email is squarely the second category. If you genuinely only ever fire transactional sends from within request handlers via an external API and never receive, never schedule, and never need a retrying consumer, Pages will work, and you can always migrate later. But that's a narrow slice, and most email apps outgrow it on week one.

Worth noting on direction: Cloudflare has been steering new full-stack projects toward Workers with static assets and converging new features there first. Pages isn't going away, but if you're starting fresh in 2026 and there's any chance you'll want bindings beyond request handling, starting on Workers avoids a migration. For the deeper "is the platform even ready for this" question, see whether Cloudflare is ready for production email, and once you've committed to Workers, the 12-point Cloudflare Workers email checklist covers the production boxes still left to tick.

How Tinbox makes the choice (so you don't have to)

Tinbox is a self-contained email stack (transactional sender, newsletter tool, and a webmail inbox) that deploys to your own Cloudflare account, and it runs as a single Worker with static assets, for exactly the reasons above. The webmail UI ships as static assets served from the edge; the same Worker exports the fetch handler for the API, the queue consumer for sending, the scheduled handler for campaigns, and the email handler for inbound mail. There's no Pages project, no second deployment to drain the queue, no coordination layer.

You don't configure any of that by hand. The bootstrapper writes the wrangler.jsonc (assets binding, D1, R2, Queue producer and consumer, Cron Triggers, and the Email Routing wiring) and provisions the resources:

npx tinbox init yourdomain.com

✔ Provisioned D1 database (tinbox-yourdomain-db)
✔ Provisioned R2 bucket (tinbox-yourdomain-mail)
✔ Provisioned Queue (tinbox-yourdomain-send)
✔ Wrote wrangler.jsonc (assets + queue consumer + cron + email handler)

Next: add the printed DNS records, then `npx tinbox deploy`.

One deployment carries the UI and every background handler. That's the payoff of the Workers-with-assets model, and it's why the Pages-vs-Workers question, for an email app, has one answer.

One honest caveat to set expectations: a Tinbox deploy is scoped to a single brand and domain. You run many tenants per Cloudflare account by doing separate deploys, one per domain. Multi-domain-per-instance is designed but not yet built, so don't plan on a single deployment fronting many domains today.

If you want the full picture of what lands on that single Worker, see the Tinbox overview, and if your specific question is just outbound sending from the edge, sending email from a Cloudflare Worker covers why HTTPS, not SMTP, is the only path.

Deploy this yourself: npx tinbox init yourdomain.com. The generated wrangler.jsonc and the Cloudflare static assets docs are the two things to read next.