R RELAY Open · Federated
The hard part was never building it

The web
belongs
to all

Building a website is easy now. Putting one online is not. The web has landlords now, and the deal is the old one: you make the thing, they keep it, and you pay to reach it. Relay is the last mile — static hosting, an easy database, reachability, and opt-in login and stats — so the thing you made can actually be seen.

No central accounts · No permission slips · Your files come with you

01 — The problem

A graveyard
of localhosts

Let's say you made something. An afternoon's work, maybe less. And now it sits in a folder — untracked, unbacked-up, seen by no one. Loved, and effectively indeployable by a normal person.

Even the ones served from home are invisible: behind a router, behind NAT, on a dynamic IP, on a machine nobody can reach.

The web has been captured. What began as a decentralized commons became five websites owned by five companies, all hosted on three clouds — the plague of landlords, now digital.

Making things got easy. Shipping them never did.

A folder is not a website.
It's a draft. Relay gives it an address.

02 — The building blocks

Three primitives.
No more.

01

Static hosting

Point Relay at a folder and it gets an address. No build step, no server to babysit, no database to provision before page one. Files are light — which is why one cheap machine can hold thousands of them.

Thousands of sites · one machine
02

An easy database

Your site remembers. One uniform store, on every server. Export the file and it travels: data that moves is data that lives.

Portable · yours to carry
03

Reachability

An outbound connection to a public friend. No port forwarding, no static IP, no dynamic DNS. It fronts a folder you point it at — or the server you already run. The world comes in through the wire you opened.

NAT is not a wall
03 — The opt-ins

Login and stats.
Only if you ask.

Opt-in login

Accounts you host

Turn it on and your site's users live in your site's own database — sign-up, sign-in, sessions — with no Relay account anywhere. Export the site and its people come with it.

Private stats

Numbers, not surveillance

Your node already served every request. It can show you views, referrers, and top pages — first-party, cookieless, aggregate, and yours alone. No tracker follows your visitors.

04 — The network

Every node is the same.
Some are public.

Visitorsa browser asks forrelay.cloudpunk.org/raspberry/docs/
Public noderelay.cloudpunk.org /raspberry/ → its outbound WebSocket /bookshelf/ → its outbound WebSocket
Raspberry Pibehind NAT/raspberry/
Laptopbehind NAT/bookshelf/

The friend nodes dial out to the public node — one WebSocket each — so no port forwarding is ever needed. The public node keeps the list, routes each request to the right friend by its path prefix, and the answer travels back up the same wire. The same wire fronts a folder of files or an app you already run — so it is also a tunnel service you own. A boring trick with a boring name; it is the reason the computer under your desk can be a web server.

05 — The doors

Open or private

Open servers

Free deployments

Anyone can publish, within the server's published rules. Personal sites, community pages, and experiments live here.

Private servers

By invitation

The owner issues a token; only sites bearing it can deploy. Families, clubs, and small businesses get a space gated by trust, not by somebody's account system.

KEY
06 — The deed

One address,
one key

The first time you deploy a name, Relay hands you a key — a small text file. That key is the deed. Update, move, or leave: the name stays yours. No landlord can claim your domain, overwrite your files, or impersonate your site. There is no password reset and no support ticket. That's the deal, and it's a good one.

07 — The rules

Rules in the open

What a server will and won't host is published, and checked by small local classifier models. Compliant sites deploy themselves. The rest wait for a human, not a platform.

  • Read the rules
  • Argue with them
  • Fork the server
08 — Next

Compute, soon

Backend functions, sandboxed in a tiny QuickJS engine and rate-limited per site. A few hundred nodes lending spare cycles become a backend nobody owns. We already built the wire — compute is the next thing we send down it.

  • Functions beside your site
  • Memory & time caps per call
  • One sandbox, a thousand tenants
09 — Self-serve

Deploy a site.
Run a node.
Take the web back.

Everything below works right now, on this node — no central account, no sign-up, no permission slip. A folder becomes a website, one command installs a node, and the admin page hands out the keys.

01

Deploy a static site

Ask the operator for a deploy key — or issue one yourself on the admin page. Tar your folder, upload it, and the site goes live at /<node>/<site>/.

tar -C ./site-folder -cf site.tar .
curl -X POST \
  -H "Authorization: Bearer $RELAY_DEPLOY_TOKEN" \
  -H "Content-Type: application/x-tar" \
  --data-binary @site.tar \
  "$RELAY_ORIGIN/_relay/v1/sites/docs/deploy"

$RELAY_ORIGIN is this node's address · $RELAY_DEPLOY_TOKEN is your deploy key

One request · atomic · rollback kept
02

Run a node

Relay is one binary. Install it, then start a node — the same code runs public or private, at home or in a cluster.

curl --proto '=https' --tlsv1.2 -sSfL \
  https://raw.githubusercontent.com/nemoNoboru/relay/main/install.sh | sh

relay node --data /var/lib/relay --listen :8080
Binary · Docker · Swarm · Kubernetes
03

Operate

The node prints an admin token on first start. It unlocks the operator console — issue and revoke deploy keys, list sites, and roll a deploy back.

Admin console at /_relay/admin.html

Of the web · by the web · for the web

Binary · Docker · Docker Swarm · Kubernetes