RTEdge.net - Overview | RTEdge.net docs

Concepts and usage

RTEdge.net turns the state of a playground into a site. You choose a route and deploy, and the HTML, the exported files and the workers you were editing are served from the edge. The same worker code runs in the playground and on RTEdge.net.

Routes, not servers

You deploy to routes. A route is a host and an optional path. A bare name such as name is the subdomain name.rt.ht, and a name with a dot, such as example.com/docs, is your own domain. One deploy publishes the same state to every route you list. Each directory is its own deployment, with no fallback to its parent.

Route	Served at
`name`	`https://name.rt.ht/`
`name/docs`	`https://name.rt.ht/docs/`
`example.com`	`https://example.com/`

See Domains and subdomains and Request routing.

What a deploy publishes

A deploy compiles the playground state into a deployment: the root document, the files you export with o:, an edge worker, a small record of the owner and the editors, a version in the history, and a screenshot that becomes the default social image. See Anatomy of a deployment and Deploying to RTEdge.net.

The network

RTEdge.net runs on Cloudflare's global network, so a request is answered in a data center near the visitor. The network spans 337 cities in 125+ countries, with 500 Tbps of capacity, and it is under 50 ms for 95% of Internet users. One shared router answers every route, and the worker of each route is its own isolated script, so a deploy never touches the router.

The map at rtedge.net shows the network. Choose File ▸ Edge ▸ Network in the playground to open it. lt.rt.ht compares RTEdge.net with other platforms from your own browser. Elefunc's own sites, such as elefunc.com and that map, run on RTEdge.net, and appending ? to their addresses opens their source.

Every name is its own site

rt.ht is on the Public Suffix List, as one of the shortest public suffixes, so every name.rt.ht is its own site. Browsers keep the cookies, the storage and the sign-in sessions of different names apart. The path routes of one host share one origin. Each custom domain is a site of its own too.

Suffixes on every URL

A few suffixes work on every deployed URL and lead back to the source, the history, the worker and the sign-in.

Suffix	What it does
`?`	Opens the deployment's source in RTCode.io, if its owner allows it.
`??`	Opens the versions of the deployment.
`*`	Lists the deployments you can edit under a host or path.
`/:`	Sends the request straight to the worker.
`::si` `::sa` `::su` `::so`	Signs in, signs in as another account, returns the signed-in user, and signs out.

More suffixes, several of them experimental, are on URL suffixes.

Sign-in without code

You sign in with GitHub, Google, Microsoft or Apple. Multi-factor sign-in and passkeys work through your identity provider. Sessions are signed with ECDSA P-384 and checked at the edge. A page links to ::si and reads the user with fetch('::su'), and a worker reads request.rt.user, so you write no authentication code. On a deployed host:

html

<a href=::si>Sign in</a> <a href=::so>Sign out</a>
<output id=who></output>
<script type=module>
  who.value = await fetch('::su').then(r => r.json()) ?? 'signed out'
</script>

See Adding sign-in.

Who can see what

edge:user restricts who may view a page. io:user and io:guest decide who may open its source. Anyone can open the source of a deployment with ?, until the deployment has an edge worker without io:guest, or an access attribute: then only its owner, its editors and the permitted accounts can. edge:redact and edge:remove only change the served HTML. The source stays visible through ? unless access is restricted. See Restricting access and Keeping secrets out of deployments.

Edge workers and scoped KV

A <script type=worker edge> runs in the playground and, after a deploy, on RTEdge.net. It answers route/:… and whatever no file or page answers. Its env.KV opens a key-value store scoped to the user, the domain or the route: values up to 10 MiB on RTEdge.net, and up to 64 KiB in the playground, where the data stays in the browser.

html

<script type=worker edge>
  export default { fetch: request => new Response(`Hello, ${request.rt.user ?? 'visitor'}`) }
</script>

See Using workers, The edge worker runtime and Storing data in KV.

Versions and screenshots

Each deploy is recorded as a version of its route, with a screenshot. Compare versions, restore one, open the history of any deployment with ??, and press Ctrl+Z / ⌘+Z past your local edits to walk back through deployed versions with Smart Undo. The screenshot is also the default image of the page when someone shares its link. See Versions and Smart Undo and Social previews and screenshots.

The playground and the edge

The playground is the same page and the same workers, running live in your browser. A few things exist only on RTEdge.net, such as the source link, versions, the index, sign-in suffixes and social tags, and a few behave differently, such as the size of a KV value and how paths reach a worker. Playground and edge differences lists them all.

Tutorials

Getting started: From an empty playground to a live deployment: write HTML, watch it sync both ways, nudge a value, sign in, pick a route and deploy.
Building a full-stack app: Build one HTML file with a worker API, per-user KV storage and sign-in, test it in the playground, then deploy it to RTEdge.net.
Pairing with an AI agent: Share a playground folder with an AI agent, let it edit, read the console and screenshots, place pins, and run evals.

Guides

Deploy

Deploying to RTEdge.net: Choose routes, deploy with one keystroke or from code, add a message, open, and delete deployments.
Domains and subdomains: Claim a name.rt.ht subdomain, connect your own domain, and understand how routes map to hosts and paths.
Versions and Smart Undo: Compare and restore versions, browse them online, and undo into deployed history.
Social previews and screenshots: The automatic og:image screenshot and default tags, and how to set your own title, description and image.

Sign-in and access

Adding sign-in: Sign visitors in with GitHub, Google, Microsoft or Apple using four-character URL suffixes, and read the user in pages and workers.
Restricting access: Choose who may view a deployment and who may open its source.
Keeping secrets out of deployments: What copy:redact, edge:redact and edge:remove hide, what stays visible through the source view, and how to keep private things private.

Workers and data

Using workers: Write backend code in a worker that runs in the playground and, with edge, on RTEdge.net.
The edge worker runtime: How a deployed worker runs: bundling, compatibility settings, which requests reach it, outbound requests, errors and limits.
Storing data in KV: Open user, domain or route scoped key-value storage and store values in the playground and on RTEdge.net.
Importing modules and WebAssembly: Import modules from URLs and run WebAssembly in the playground and at the edge.
Post-quantum cryptography: Post-quantum TLS on RTEdge.net hosts, and ML-KEM and ML-DSA in Web Crypto for edge workers.

Operate

Usage and tail logs Experimental: Watch the usage of a deployment and stream its worker logs.
Web Push Experimental: Send push notifications to yourself from pages and workers.
Coming soon Coming soon: What is announced, and how it will fit in.

Concepts

Architecture: How the editor, the isolated output, the deploy pipeline and the edge fit together.
Request routing: The order in which RTEdge.net answers a request, and how a URL finds its route.
Anatomy of a deployment: What one deploy produces: the page, files, worker, metadata, version and screenshot.
Security and access model: Sites, sessions and permits: who can view a page, and who can open its source.
Playground and edge differences: Everything that behaves differently in the playground and on RTEdge.net, in one table.

Reference

Platform reference

Response headers: The headers RTEdge.net adds to deployed pages, files and worker responses.
Error pages and status codes: What visitors see for missing code, missing files, sign-in requirements and worker errors.
Limits and quotas: Size, worker, subdomain and storage limits that apply by default.
Reserved paths: Paths the platform answers on every host, and paths deployments cannot use.
Glossary: Terms used across RTCode.io and RTEdge.net.

URL suffixes

URL suffixes: Every suffix and special query that RTEdge.net understands on deployed URLs, in one table.
?: Opens a deployment's source in RTCode.io.
??: Opens the versions of a deployment.
*: Lists the deployments you can edit under a host or path.
/:: Sends a request straight to the deployment's worker.
::si ::sa ::su ::so: Sign in, sign in as, read the signed-in user and sign out.
Query parameters: Social preview overrides, content-type overrides and other query parameters.

Attributes and elements

o:: Exports an element as a file served at /name.ext.
h:*: Adds a response header to an exported file or worker asset.
worker:fs: Binds the element's content to the worker as an env.FS asset.
edge:user: Restricts who may view a deployment.
io:user: Restricts who may open a deployment's source in RTCode.io.
io:guest: Lets anyone open the source of a deployment that has an edge worker.
edge:redact: Replaces the element with a comment in the deployed page.
edge:remove: Removes the element from the deployed page.
<script type=worker>: Holds the worker code that answers requests in the playground and, with edge, on RTEdge.net.

Worker runtime

The fetch() handler: The function a worker exports to answer requests, and its request, env and ctx arguments.
Request.rt: Platform metadata on every request a worker receives.
env: The worker's bindings: env.FS assets and env.KV storage.
KVNamespace: A scoped key-value namespace opened with env.KV.open().

Playground API

Code: Deployment configuration of the playground: routes and editors.
edge: Deploy, measure and browse versions from code.
edge.save.limit(): Deploys the playground to every route, or deletes deployments.
edge.size(): Measures the source, its files and worker, locally, deployed or for a saved version.
edge.versions(): Lists past deployments and writes any of them into the agent folder.

Utilities

Utilities: Public helper hosts that complement RTCode.io and RTEdge.net, with their status.
in.rt.ht and short links: Open any deployment through one gateway and use rt.ht short links.
lt.rt.ht: Compare RTEdge.net latency with other edge platforms from your browser.

Examples

A page with a worker

The page asks its worker, with :me, who is calling. In the playground the answer is your RTCode.io account, or visitor when you are signed out. Deployed to a route, it is the visitor who is signed in on that host. Add a link to ::si to let people sign in.

html

<h1>Hello, <output id=who>visitor</output></h1>
<script type=module>
  who.value = await fetch(':me').then(r => r.text())
</script>
<script type=worker edge>
  export default { fetch: request => new Response(request.rt.user ?? 'visitor') }
</script>

Per-user storage

The worker counts the visits of each signed-in user in the user and route scope. It calls KV.open() without await, and it checks the user first: without that check, a signed-out visitor would open the scope that every visitor shares. In the playground the data lives in the browser and is capped at 64 KiB.

html

<output id=out></output>
<script type=module>
  out.value = JSON.stringify(await fetch(':visits').then(r => r.json()))
</script>
<script type=worker edge>
  export default {
    fetch: async (request, { KV }) => {
      const { user, route } = request.rt
      if (!user) return Response.json({ error: 'Sign in first' }, { status: 401 })
      const kv = KV.open({ user, route })
      const visits = (await kv.get('visits', 'json') ?? 0) + 1
      await kv.put('visits', JSON.stringify(visits))
      return Response.json({ user, visits })
    }
  }
</script>

Specifications

Not part of any specification. RTEdge.net is a deployment network operated by Elefunc, Inc. It builds on these standards:

Specification
HTML Standard
Fetch Standard
URL Standard
RFC 9110: HTTP Semantics
RFC 8446: TLS 1.3
Web Cryptography API
The Open Graph protocol
Public Suffix List
Cloudflare Workers runtime: web standards

Availability

Feature	Playground	RTEdge.net	Notes
Exported files (`o:`)	Yes	Yes	At `/name` in the playground output, and at `route/name` on RTEdge.net.
Edge worker (`<script type=worker edge>`)	Yes	Yes	In the playground it runs in a browser service worker.
The signed-in user (`request.rt.user`, `::su`)	Yes	Yes	In the playground it is your RTCode.io account.
Sign-in suffixes (`::si`, `::sa`, `::so`)	No	Yes	The playground emulates `::su` only.
Scoped KV (`env.KV`)	Partial	Yes	Browser storage and 64 KiB per value in the playground. 10 MiB per value on RTEdge.net.
Source, versions and index (`?`, `??`, `*`)	No	Yes	These suffixes belong to the edge router.
Routes, custom domains, social tags, screenshots	No	Yes	You deploy from the playground to reach them.
Smart Undo through deployed versions	Yes	No	A playground feature that reads the history of a deployed route. It needs sign-in.

A deployment is an ordinary HTTPS site that any browser can open. RTEdge.net hosts offer the hybrid post-quantum key agreement X25519MLKEM768 to browsers that support it; see Post-quantum cryptography. The playground you deploy from has its own browser requirements; see Browser support.