Playground and edge differences

Overview

These parts are the same in both places:

• The handler forms, such as export default { fetch(request, env, ctx) { … } }, and the (request, env, ctx) signature.
• env is exactly { KV, FS }, and env.KV.open() takes the same scopes, depth and key rules.
• A : in a URL reaches the worker: the part after the first : becomes the worker's pathname.
• Exported files answer before the worker, for any HTTP method.
• request.rt.user holds the signed-in email, or null.

Everything else that differs is in the table. Each row has its own anchor, so you can link to it. The facts are as of 2026-10-04 and describe the current shell, 2026-04-30; see Guarantees and limits for older deployments.

Why they differ

The playground and RTEdge.net are different runtimes. Worker code runs in a service worker in your browser in the playground, and on Cloudflare Workers for Platforms after a deploy, so the APIs, the limits, the storage and the routing differ. Architecture follows both paths.

Files are extracted twice. The editor extracts exports and worker assets from the live input, in your browser. The deploy compiler extracts them again on the server, with a different DOM implementation and a cleanup step that strips RTCode attributes and applies redaction. Both use the same tables and defaults, which is why most files look the same.

Finally, the platform stands in front of every deployment. Redirects, protection and suffix handlers answer before your code, and the access rules are enforced there. None of that exists in the playground output.

Telling the runtime apart

Branch on request.rt.edge, which is true only on RTEdge.net. In the playground, request.rt.code is true instead.

export default {
  fetch: request => new Response(request.rt.edge ? 'RTEdge.net' : 'Playground')
}

For a feature, detect the feature itself. For example, globalThis.Cloudflare?.compatibilityFlags?.webcrypto_modern_algorithms exists only at the edge, and crypto.subtle.constructor.supports?.('encapsulateBits', 'ML-KEM-768') works in both places when supports exists. See Post-quantum cryptography.

Code that behaves the same

• Reach your worker with : URLs in both places, as in <iframe src=:> and fetch(':api').
• Use absolute URLs for outbound requests, and worker:fs assets for your own files.
• Keep work that needs a request inside the handler. Do not call fetch() or set timers at the top level of the module.
• Check request.rt.user before you open a per-user KV scope. A falsy user opens the shared owner scope in both places.
• Store strings in KV, and keep each value under 64 KiB if the playground has to hold it.
• Do not rely on redaction to hide a secret. It changes only the served page. See Keeping secrets out of deployments.
• Test cross-origin calls and large KV values on RTEdge.net before you rely on them.

Guarantees and limits

The table describes the playground and the current shell, dated 2026-04-30, as of 2026-10-04. The shell is the wrapper that RTEdge.net compiles around your edge worker. A deployed worker keeps the shell, the compatibility date and the compatibility flags of its last deploy until you redeploy it, so an older deployment can differ from the table. The compatibility date is the UTC date of that deploy.

Redeploy a route to move it to the current shell.

Related concepts

Architecture

How the editor, the output, the deploy pipeline and the edge fit together.

Request routing

The order in which the playground output and RTEdge.net answer a request.

Anatomy of a deployment

What one deploy produces and how each part is served.

Security and access model

Sessions, owners, editors and permits, which RTEdge.net enforces.

See also

• Using workers
• Edge worker runtime
• Request.rt
• Storing data in KV
• Exporting files
• Limits and quotas
• Glossary