1. First, distinguish them in one sentence: Workers are “running code at the edge,” Pages are “publishing your website out there”
Many people feel a bit confused the first time they look at Cloudflare’s products: Workers, Pages, R2, KV, D1, Queues… which one should I use?
First, remember the most intuitive analogy:
- Workers is more like “a program running on Cloudflare’s global nodes.” What you write is server-side logic, such as APIs, authentication, forwarding, data processing, A/B testing, dynamic rendering, and so on.
- Pages is more like “deploying a frontend project into a website with one click.” It excels at static sites (HTML/CSS/JS) as well as SSR/edge functions for some frameworks (via Pages Functions).
If you don’t want to memorize concepts, you can think of it this way:
- If you want to build a “backend”: lean toward Workers.
- If you want to “launch a website”: lean toward Pages.
Of course, the two can be used together, and in many projects it’s common to see “frontend on Pages, backend on Workers.”
2. What they have in common: why are they often discussed together?
Workers and Pages are often mentioned together because they share a large set of fundamental capabilities:
- Both run on Cloudflare’s global edge network
- That means they are not deployed on one fixed server, but instead are placed as close to visitors as possible.
- The result is usually: faster access, lower latency, and more consistent cross-region experience.
- Both natively connect to Cloudflare’s security and networking capabilities
- DDoS protection, WAF (if enabled), Bot management, TLS certificates, CDN caching, etc.
- You don’t need to configure Nginx yourself, buy certificates, or set up a pile of security policies.
- Both can be bound to your own domain
- For example,
api.example.comfor Workers. www.example.comfor Pages.
- For example,
- Both can work with Cloudflare’s storage/database offerings
- Such as KV, D1, R2, Durable Objects, Queues.
- In real projects, it’s often not “use only Workers or only Pages,” but rather a combination of “website + data + logic.”
- Both support Git-driven development (especially Pages)
- Pages is basically “connect GitHub/GitLab, deploy on push.”
- Workers can also use
wranglerwith GitHub Actions for continuous deployment.
3. Core differences: their “product positioning” is different
Below, let’s look at the differences from a more practical perspective.
3.1 What you deploy is different
- Workers: you deploy code (a server-side program)
- What you publish is a worker script.
- It receives requests (HTTP), processes logic, and returns responses.
- Pages: you deploy website artifacts (static assets)
- What you publish are built files, such as
index.html,assets/xxx.js,style.css. - Pages distributes those files to edge nodes and returns them to users from the nearest location, just like a CDN.
- What you publish are built files, such as
3.2 Where “dynamic capabilities” come from is different
- Workers’ dynamic capability: it is natively about writing code to handle requests.
- Pages’ dynamic capability: it mainly comes from Pages Functions.
- You can write functions in a Pages project to handle
/api/*or certain routes. - But its positioning is still “website first, functions as a supplement.”
- You can write functions in a Pages project to handle
3.3 Typical use cases are different
- Workers is better suited for
- API gateways: unified authentication, rate limiting, logging, canary releases.
- BFF (backend for frontend): aggregates multiple backend APIs into a single endpoint.
- Lightweight backends: form submissions, email notifications, webhook handling.
- Edge computing: image processing, text processing, content rewriting.
- Reverse proxying and request rewriting: forward requests to third-party services, with signing and header injection.
- Pages is better suited for
- Corporate websites, product landing pages.
- Documentation sites (Docusaurus, VitePress, Next.js static export, etc.).
- Blogs (Hugo, Hexo, Astro).
- Single-page applications (React/Vue/Svelte) deployment.
- Frontend projects that need preview environments (each PR automatically generates a preview link).
3.4 Development Experience Differs
- Pages feels more like a “hosting platform”
- Connect your Git repository.
- Automatic build and deployment.
- Has Preview environments (PR previews).
- Suits frontend team workflows.
- Workers feels more like “cloud functions/Serverless”
- Use
wranglerto initialize, develop, and publish. - Focus more on routing, request handling, binding environment variables, and accessing KV/D1/R2.
- Suits backend/full-stack workflows.
- Use
4. Using a “bubble tea shop” example to explain: when to use Workers and when to use Pages?
Imagine you own a bubble tea shop and want to build an online system:
- You need an official website to showcase the menu, store locations, and promotional posters.
- You also need an ordering API where users can submit orders, payment callbacks are handled, and order statuses can be queried.
In this case:
- Pages = the storefront display window
- Menu images, campaign pages, intro copy.
- Most content doesn’t change every second, so static hosting fits perfectly.
- Workers = the staff and cashier system
- Receives order requests.
- Validates coupons.
- Calls the payment platform.
- Writes orders into the database.
You could certainly use only Workers to output web pages (Workers can return HTML too), but that’s more like “having staff manually arrange the storefront”—it’s possible, but not cost-effective.
Conversely, you could also use Pages Functions for some dynamic APIs, but if the business logic becomes increasingly complex, you’ll eventually find yourself writing something that feels like a backend—and naturally you’ll migrate to Workers.
5. What can you do with Cloudflare’s free plan? (Viewed from “can you get started”)
Cloudflare’s free plan is very friendly for individual developers, small-team prototypes, and learning projects. Think of it this way:
- It’s enough to get a website online (Pages’ free tier is quite strong).
- It’s also enough to write lightweight APIs (Workers can run on the free tier).
Normally, you can accomplish the following within the free tier:
5.1 Use Pages to launch a site for free
On the free plan, you can:
- Connect a GitHub repository and auto-deploy on push.
- Generate Preview links (very useful for collaboration).
- Bind a custom domain with automatic HTTPS.
- Host static site assets.
Good examples:
- Personal blog.
- Product introduction page.
- Open-source project documentation site.
- Frontend demo.
5.2 Use Workers to write a lightweight API for free
On the free plan, you can build:
- A
GET /api/helloendpoint. - Form submission endpoints:
POST /api/feedback. - Webhook receivers (e.g., receiving payment success callbacks).
- Reverse proxies: forward requests to another service with authentication.
Combined with the free tiers of products like KV, D1, and R2 (each product has different policies, but there’s usually a free layer), you can put together a usable “mini backend”.
说明：免费套餐的具体额度会随 Cloudflare 调整而变化。选择前建议以 Cloudflare 官方页面的最新说明为准。
6. Summary table of “similarities vs differences” between Workers and Pages
| Dimension | Workers | Pages |
|---|---|---|
| Purpose | Run code at the edge (backend/logic) | Website hosting and publishing (frontend/static assets) |
| Primary output | Scripts and routes (request handling) | Built site files (HTML/CSS/JS) |
| Dynamic capabilities | Native and strong | Provided via Pages Functions |
| Typical workflow | Develop and deploy with wrangler | Connect Git; push to deploy; PR previews |
| Ideal for | Backend, full-stack, platform engineering | Frontend, content, product, growth |
| Common use cases | APIs, auth, aggregation, proxies, compute | Corporate sites, blogs, docs, SPAs |
7. Pros and Cons of Workers (Plain-Language Version)
7.1 Advantages of Workers
- “Handle requests however you want”
- You can read headers, rewrite URLs, query databases, and perform signature validation.
- Great for complex business logic.
- Edge execution gives you good speed and stability
- Users around the world can be served from the nearest location.
- Good for latency-sensitive APIs.
- Excellent as a “middle layer”
- Combine multiple services into one frontend-friendly API.
- For example, aggregate user information, order data, and recommendations into a single request.
- Plays well with the Cloudflare ecosystem
- KV: configuration, sessions, caching.
- D1: structured data.
- R2: object storage.
- Durable Objects: scenarios that need strong consistency or single-point state.
7.2 Disadvantages of Workers
- “Strong backend capabilities” means you take on more backend design work
- How is auth done?
- How are error codes defined?
- How is data stored?
- How are logs emitted?
- It is not a “full server” in the traditional sense
- The runtime, limits, and request-handling model are not exactly the same as a traditional Node/VM.
- Scenarios that depend on a local file system or long-lived connections need a different approach.
- As projects grow, you need more systematic engineering practices
- Multiple environments, canary releases, monitoring, alerting, rollback.
- All of this is possible, but it requires you to set up the discipline.
8. Pros and Cons of Pages (Plain-Language Version)
8.1 Advantages of Pages
- Deploying a website is worry-free
- Connect your repository.
- Configure the build command.
- Push and it goes live.
- Excellent static site performance
- Static assets are naturally suited to CDN distribution.
- This is usually better for SEO and first-paint speed.
- Preview environments are great for collaboration
- Every PR can generate an accessible preview link.
- Designers, product managers, and testers can simply click and see the result.
- Friendly to common frontend frameworks
- React/Vue/Svelte/Next/Astro all have mature ways to deploy.
8.2 Disadvantages of Pages
- At its core, it is still “website hosting”
- Once your need becomes “I want a complex backend,” Pages is no longer the main battlefield.
- Pages Functions can do some of it, but it’s better suited to lightweight APIs.
- Dynamic capabilities and state-management complexity escalate quickly
- For example, if you need login, sessions, permissions, orders, etc.
- Cramming everything into Pages Functions can make the project structure unclear.
- For fully dynamic sites, it is less natural than pure Workers
- If every page must be assembled in real time and depends heavily on data APIs, Workers is often more convenient.
9. Workers vs Pages: How to Choose? A Simple Decision Method
Work through the questions below:
9.1 Is your primary output “web page files” or “API logic”?
- Mostly web pages: choose Pages.
- Mostly APIs: choose Workers.
9.2 Do you need a Git-driven preview and release workflow?
- Need very standard front-end CI/CD: prefer Pages.
- You care more about server-side logic and routing: prefer Workers.
9.3 Do you need complex authentication, rate limiting, or data processing?
- If yes: lean more toward Workers.
- If you only need simple forms or simple endpoints: Pages Functions or Workers both work.
9.4 Recommended combination (most common and most reliable)
- Pages for the frontend + Workers for the API
- Domain example:
www.example.com→ Pagesapi.example.com→ Workers
- The benefit is clear separation of responsibilities:
- Pages 专注“展示”。
- Workers 专注“逻辑”。
- Domain example:
10. Two small examples: easy-to-understand usage
Example A: Personal blog + comment submission
- Blog pages: use Pages
- Build with Hugo/Hexo/VitePress and publish directly.
- Comment submission API: use Workers (or Pages Functions)
POST /api/comment- Validate parameters.
- Write to D1.
- Return the comment ID.
You’ll see: blog content is static, so Pages fits; comments are dynamically written, so Workers fits.
Example B: Wrap a third-party API for authentication and caching
Suppose you want to call a third-party weather API:
- You don’t want to put the third-party key directly in the frontend.
- You also want caching to reduce the number of calls.
In this case, Workers is the best fit:
- The frontend requests your endpoint:
GET /api/weather?city=shanghai - Workers checks the cache (KV).
- If there’s no cache, it requests the third-party service.
- It writes the result to KV and sets an expiration time.
- It returns the result to the frontend.
Pages can also “host frontend pages,” but this “middle layer” logic is clearly where Workers excels.
11. Final advice: start with the simplest combination
If you’re starting a project from zero, the most reliable path is usually:
- Get the website running on Pages first (fastest to launch, lowest cost).
- When you need an API, add a Workers service.
- Choose KV, D1, or R2 for storage based on your needs.
The benefits of this approach:
- Fast launch.
- Clear architecture.
- Plenty of room to grow later.
Comments