The edge worker runtime

From a script to a deployed worker

Each route has at most one edge worker. At deploy, RTEdge.net takes the <script type=worker edge> elements of the playground page, builds one ES module and uploads it as a Cloudflare Workers for Platforms user worker for that route. The edge router sends the requests for the route to it.

• Only script[type=worker][edge] is deployed, and the edge attribute may have any value. Worker scripts without it run only in the playground.
• Every <script type=worker>, with or without edge, is blanked out of the served page and replaced by line breaks, so the line count stays the same. The source that ? opens still contains them.
• Several edge scripts are joined with a newline, in document order, into one. The fetch attribute and the edge value come from the first edge script. Source-privacy attributes are read from every edge script.
• Deploying a page with no edge script deletes the route's existing worker.
• Before the upload, the compiler parses your worker code and prints it again from the syntax tree, applies the handler transform and inserts the result after the wrapper that RTEdge.net adds (the shell). Comments and your formatting are not kept, so line and column numbers in stack traces refer to the compiled script, not to the playground source.
• io:host and io:fail do not affect deployed workers. The compiler reads only edge, fetch, io:user, edge:user and io:guest from worker elements.
• Static URL imports are bundled and frozen at deploy, and WebAssembly is extracted into pre-compiled modules. See Importing modules and WebAssembly.

Compatibility settings and bindings

Every upload uses the same settings, and you cannot change them. The compatibility date is the UTC date of the deploy, so date-gated changes in the Cloudflare runtime reach a worker only when you deploy it again.

A worker has exactly two bindings, env.KV and env.FS. There are no environment variables or secrets, Durable Objects, R2, D1, Queues, service bindings, AI, Vectorize, Analytics Engine, Hyperdrive, Browser Rendering, send_email or rate-limit bindings, and no cron triggers. Code cannot declare any of them. A secret has to live in the worker source, which is private unless you add io:guest.

Shell versions

The wrapper that RTEdge.net compiles around your code is called the shell. Its version date is baked into each worker at deploy. It shows as request.rt.worker.version.shell and in the edge-worker header, and the current shell is 2026-04-30. A deployed worker keeps the behaviour of its shell until you redeploy it, covering the fields of request.rt, the KV API and its size limit, the patched fetch(), env.FS, the error pages and the compatibility settings.

Not every build with a given shell date has every change. Redeploying always gives you the current behaviour.

The handler and its response

The accepted forms are the same as in the playground, because both use one transform: export default { fetch(request, env, ctx) { … } }, with async or as an arrow function, and a module-scope function fetch declaration. Each becomes a module-scope async function fetch(…). See The fetch() handler for the forms that do not work. Only fetch is wired: scheduled, queue, email and tail members never run.

The handler is called as fetch(request, env, ctx). ctx is Cloudflare's ExecutionContext, passed through unchanged, so ctx.waitUntil() works.

• Return a Response or a promise of one. The wrapper copies it, carrying over the status, status text and headers, which become mutable, and sets an edge-worker header of the form fetch="<deploy time>"; shell="<shell date>", host="CF:WfP", replacing any header of that name.
• undefined produces the 501 page. null, a string or a number throws a TypeError and produces the exception page.
• Do not use the statuses 598 or 599. The platform reserves them as signals between the wrapper and the router, and a response that uses one is not delivered as you wrote it.

Module scope and runtime

• The module is evaluated once per isolate, so module-level state may persist across requests. Isolates are evicted unpredictably: do not rely on that state. In the playground, the top-level code runs again for each request.
• eval() and new Function(text) throw while a request is handled. Cloudflare allows them during startup for compatibility dates from 2025-06-01, which every current deploy has, so code that you generate at the top level is expected to work. In the playground both work everywhere, so a library that generates code per request, such as some template engines, can pass there and fail at the edge.
• Date.now() advances only with I/O. It does not move during pure computation.
• A fetch() or a timer at the top level throws during startup and fails the upload. Do that work inside the handler and cache the result or the promise. Building WebAssembly instances from extracted modules at the top level is fine.
• navigator.userAgent is Cloudflare-Workers at the edge, and the global Cloudflare.compatibilityFlags exists. The playground has neither.

Which requests reach the worker

See Request routing for the full order in which RTEdge.net handles a request.

The incoming request

• request.url keeps the visitor's scheme, host and query string. For a : call, the pathname is the text after the first :, without the route prefix.
• The method, the headers and the body are preserved, and page navigations keep all three. In the playground a navigation arrives as a bare GET.
• The Cloudflare headers CF-Connecting-IP, CF-IPCountry and CF-Ray are not in request.headers in shells from 2025-09-29. Read request.rt instead: ip, country, ray and colo.
• Do not rely on request.cf at the edge: use request.rt.colo and request.rt.country. request.event exists only in the playground.
• request.signal exists, because of the enable_request_signal flag.

Outbound requests

Since shell 2025-09-29 the wrapper patches the global fetch(). A string or URL input is parsed against the base https://none:

• //host/x becomes https://host/x, and absolute URLs are unchanged.
• Relative URLs, such as /x, x and ./x, become https://none/x and fail.
• Request objects pass through untouched.

Never call fetch('/data.json') at the edge. Use env.FS for files that belong to your page, or an absolute URL. Older shells have no patch, so a protocol-relative or relative URL may throw an invalid-URL error until you redeploy.

To call another deployment, use an absolute URL or the in.rt.ht gateway: https://in.rt.ht/<route>/<path> reaches any route through the edge router, and a bare name gets .rt.ht appended, as in //in.rt.ht/<route>/:….

Every outbound request passes through a platform outbound worker. It removes request headers whose names start with rt-, and the Host header, and adds its own rt- headers that identify the RTEdge route and sign the request. connect(), the TCP sockets of cloudflare:sockets, is unavailable.

Response headers

The response rules of the platform apply to the responses of workers as well. Every host gets Server-Actual: RTEdge.net and Server-Vendor. Hosts under rt.ht get Strict-Transport-Security and Referrer-Policy: unsafe-url, which overrides a Referrer-Policy that your worker sets, and hosts that are not under rt.ht get Edge: RTEdge.net. The platform does not cache worker responses, and the Cache-Control of your response passes through to the client. See Response headers.

Errors and status codes

These pages are HTML and carry no edge-worker header. Throw Error objects: a thrown string has no stack to show. A failure outside your handler, such as an exceeded resource limit, does not produce these pages, so do not depend on a specific response for it. In the playground, the equivalents are an HTTP 500 text response with a stack when io:fail is closed, and a pass-through to the network when it is open. See Error pages.

Post-quantum Web Crypto

Workers uploaded on or after 2026-10-01 have ML-KEM-768 and ML-KEM-1024 for key encapsulation and ML-DSA-44, ML-DSA-65 and ML-DSA-87 for signatures in crypto.subtle. Redeploy older workers to get them. In the playground, support depends on the browser. See Post-quantum cryptography.

Logging

The console output of a deployed worker does not appear in responses. Tail logs Experimental collect it for the route; see Usage and tail logs.

Limits

RTEdge.net sets no per-route limits of its own, so Cloudflare's default limits for Workers apply: CPU time, memory, subrequests, script size and startup time. See the Cloudflare Workers limits. Exceeding a limit fails the invocation.

By default, an account can have edge workers on up to 5 routes, within a total deployment size of 1 MB. The size counts the stored deployment, not only your source. See Limits and quotas.

What is not supported

• Handlers other than fetch: scheduled, queue, email and tail never run.
• Node.js APIs, import { env } from 'cloudflare:workers' and connect().
• Any binding other than KV and FS.
• Dynamic import() of URLs. Workers cannot load code at runtime, so use static imports.
• Server-side WebSockets with WebSocketPair are untested. Do not rely on them.

Examples

<output id=out></output>
<script type=module>
  out.value = JSON.stringify(await fetch(':hello?name=Ada').then(r => r.json()))
</script>
<script type=worker edge>
  export default {
    fetch: request => {
      const { pathname, searchParams } = new URL(request.url)
      return Response.json({ pathname, name: searchParams.get('name'), where: request.rt.edge ? 'edge' : request.rt.code ? 'playground' : '?' })
    }
  }
</script>

export default {
  fetch: async () => {
    const other = await fetch('https://in.rt.ht/wasm/:1+2').then(r => r.json())                   // another deployment, through the gateway
    const pkg   = await fetch('//cdn.jsdelivr.net/npm/marked/package.json').then(r => r.json())   // '//' becomes https:// at the edge
    return Response.json({ sum: other.streaming.z, marked: pkg.version })
  }
}

const cors = { 'access-control-allow-origin': '*', 'access-control-allow-headers': '*' }
export default {
  fetch: request => request.method === 'OPTIONS'
    ? new Response(null, { status: 204, headers: cors })
    : Response.json({ ok: true }, { headers: cors })
}

See also

• Using workers
• <script type=worker>
• The fetch() handler
• Request.rt
• env
• KVNamespace
• Request routing
• Anatomy of a deployment
• Playground and edge differences
• Deploying
• Error pages