From Cloudflare Pages to EdgeOne Makers: A Chinese Developer’s Migration Story

If you’re a frontend developer or someone who runs their own personal site, you’re probably familiar with Cloudflare Pages.

Git push, auto-build, global CDN distribution, and edge functions — a powerful combination that simplifies static site hosting to the extreme.

But if you’re serving Chinese users, things aren’t so rosy.

Cloudflare’s free plan’s access speed in China — if you know, you know. It’s okay when it’s fast, but during peak evening hours, it puts on quite a show: “spinning for three minutes, white screen for two and a half.”

Enter Tencent Cloud.

EdgeOne Makers (formerly EdgeOne Pages), as the name suggests, aims to rival Cloudflare Pages + Workers. But its roots are in Tencent Cloud’s 2800+ edge nodes worldwide — including a large number of nodes inside China, a weakness that Cloudflare simply can’t overcome.

I’ve been using it for a while, and my biggest impression is three words: truly fast.

But this article isn’t just about “it’s fast.” I want to discuss: if you’re already running smoothly on Cloudflare Pages, why migrate, how to migrate, and what pitfalls await you afterward.

What is EdgeOne Makers

Let’s clarify the name first.

If you search for “EdgeOne Pages,” you’ll find plenty of material, but Tencent Cloud has now officially named it EdgeOne Makers (it’s called Makers in the console). To avoid confusion, I’ll refer to it as Makers throughout.

Its core capabilities can be broken into three parts:

1. Static site hosting — Competes with Cloudflare Pages, supports Hexo, Vue, React, Astro, and other major frameworks. Connect your GitHub repo and it builds and deploys automatically.
2. Edge functions (Makers Functions) — Competes with Cloudflare Workers, runs JS on edge nodes without managing servers.
3. KV storage — Competes with Cloudflare KV, edge key-value storage, currently in Beta and requires application.

Domestic site: edgeone.cloud.tencent.com/pages
International site: edgeone.ai/zh/products/pages

A nice detail: domains don’t need ICP registration to work. Certificates are automatically issued, and preview domains are accessible within three hours — very friendly for developers who don’t have a registered domain on hand.

Going Head-to-Head with Cloudflare Pages

Let’s get straight to the comparison table:

The most impactful item here is domestic access speed.

Real-world tests have shown: Beijing Telecom dropped from 4.2s to 0.8s, Shanghai Unicom from 5.1s to 0.9s, Guangzhou Mobile from 4.8s to 0.7s. It’s not that Cloudflare is bad — it’s that Cloudflare has no nodes in mainland China, traffic has to take detours, and physical distance is unavoidable.

The only exception is overseas user coverage. Cloudflare’s 330+ city node density worldwide still crushes Makers. If half your users are domestic and half are overseas, you can use Cloudflare as a global layer with Makers for domestic acceleration — a dual-CDN setup is perfectly viable.

Migration Hands-On: From Cloudflare Pages to Makers

The official migration documentation exists, but it’s a bit sparse. Let me walk through the actual process step by step.

Step 1: Copy Your Config

Log in to the Cloudflare Dashboard, go to your Pages project → Settings → Build configuration, and note down these two values:

• Build command — e.g., npm run build
• Build output directory — e.g., dist, build, .next

At the same time, check if your project root has _redirects and _headers files — these are used by Cloudflare Pages for redirects and response headers, and need to be converted to Makers’ format during migration.

Step 2: Create a Project in Makers

Open console.cloud.tencent.com/edgeone/pages, click Create Project, select your GitHub repository (Gitee and Coding are also supported), fill in the build command and output directory you noted, then click Deploy.

Makers will automatically execute the build and push the output to the edge network. Within minutes, you’ll have a preview domain like your-project.edgeone.site.

Step 3: Migrate _redirects and _headers

This is where the most pitfalls lie.

Cloudflare Pages uses two text files:

# _redirects
/old-path   /new-path   301
/api/*      /api/proxy  200

# _headers
/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
/assets/*
  Cache-Control: public, max-age=31536000

Makers uses edgeone.json, placed in the project root:

{
  "redirects": [
    {
      "source": "/old-path",
      "destination": "/new-path",
      "statusCode": 301
    }
  ],
  "rewrites": [
    {
      "source": "/api/*",
      "destination": "/api/proxy"
    }
  ],
  "headers": [
    {
      "source": "/*",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" }
      ]
    },
    {
      "source": "/assets/*",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000" }
      ]
    }
  ]
}

Note: proxy rewrites (status code 200) from _redirects go into the rewrites field in Makers, not redirects.

Step 4: Migrate Edge Functions

Cloudflare Pages Functions uses the functions/ directory, with files as routes:

// functions/api/hello.js — Cloudflare
export function onRequest(context) {
  return new Response("Hello, Cloudflare!");
}

Makers Functions is fully compatible with this syntax — onRequest and the context object are essentially the same:

// functions/api/hello.js — Makers (no code changes needed)
export function onRequest(context) {
  return new Response("Hello, EdgeOne!");
}

If your functions depend on Cloudflare-specific APIs (like caches, env.KV), you’ll need to adapt them according to Makers’ documentation. Makers Functions supports Cloud Functions and Edge Functions modes, with slightly different context object properties — choose as needed.

Step 5: Switch Your Domain

Add your custom domain in Makers’ project settings and get the CNAME record value.

Then go to your DNS provider — even if your domain is still on Cloudflare’s DNS, that’s fine. You don’t need to move your DNS; just update the existing CNAME record from Cloudflare Pages’ CNAME to the one provided by Makers.

Note: If you had Cloudflare’s orange cloud (Proxy mode) enabled, make sure to turn it off and switch to DNS Only. Otherwise, Makers’ IP will be proxied through Cloudflare again, adding an extra hop.

Step 6: Verify

After DNS takes effect, use curl to check the response headers:

curl -I https://yourdomain.com

Confirm the response headers contain Makers’ identifying fields. You can also run Lighthouse or PageSpeed to compare performance before and after migration — based on community tests, domestic TTFB dropping from 0.9s to 0.3s is a common improvement.

A Few Pitfalls Worth Mentioning

To be honest, Makers is still in public beta, and not everything is perfect.

KV storage is still in Beta and requires a separate application. If you heavily rely on Cloudflare KV, confirm Makers KV’s availability and quotas before migrating. For now, I recommend wrapping your KV read logic in an abstraction layer for easy switching back later.

Overseas node coverage isn’t as good as Cloudflare. If you also serve a large number of overseas users, Makers can’t fully replace Cloudflare. Consider a dual-CDN approach: Makers for domestic acceleration, Cloudflare as a fallback for overseas.

The console entry point is a bit hard to find. When I first looked for Makers’ console, I spent ages scrolling through Tencent Cloud’s product list. Remember the shortcut: console.cloud.tencent.com/edgeone/pages.

Community and documentation are still being built. If you run into issues, scan the QR code for the “Developer Communication Group” in the top-right corner of the console and ask there — response times are decent.

Summary

Cloudflare Pages is still one of the best static site hosting solutions globally — mature features, rich ecosystem, large community.

But if you’re serving the Chinese internet audience, Makers’ improvement in domestic access speed is real. The migration cost is nearly zero (function code is compatible, Git workflow remains unchanged), while the improvement in user experience is significant — faster load times mean lower bounce rates and better SEO rankings.

My personal recommendation: new projects can go straight to Makers. For old projects that don’t heavily rely on KV/Workers advanced features, spending an afternoon migrating is worth it.

After all, when it comes to websites, speed is justice.