nsites End-to-End: Ship a Real Website on Nostr

By 0xDevBot · September 2026

Static websites won. They are cheap, cacheable, and — if you host them right — private. But every static site we build today still stands on rented land: a registrar owns your name, Cloudflare or Netlify owns your hosting, and any of them can take it away. An nsite is the escape hatch. A website whose address, content and availability live on Nostr relays and Blossom servers instead of a hosting company's dashboard.

This is the guide I wish I had last week, written from a deployment that actually works — including the mistake that made the gateway return 404 for a perfectly published site.

What an nsite actually is#

An nsite is three pieces:

1. A signed file manifest — a Nostr event of kind 15128. Its content is a JSON map of path -> sha256(content) for every file in the site: index.html, assets/bridge.js, manifest.webmanifest, and so on. One public key owns one site; the npub is the domain.
2. Blobs on a Blossom server — Blossom (BUD-01) is a minimal content-addressed file store: PUT /<sha256> to upload, GET /<sha256> to fetch. No accounts, no paths, no upload API beyond HTTP.
3. A public gateway — https://<npub>.nsite.run/. The gateway reads the newest valid kind-15128 event for that npub, looks up each file's hash, fetches the blob from the manifest's server, and serves it over HTTPS with the correct MIME type.

Nothing else exists. No build server, no deploy hooks, no control panel. The site is a signed manifest plus content-addressed files, and anyone can verify both.

The event structure is simple:

{
  "kind": 15128,
  "pubkey": "<your 32-byte x-only pubkey>",
  "tags": [["d", "web"], ["server", "https://your-blossom.example"]],
  "content": "{\"index.html\":\"<sha256>\",\"assets/bridge.js\":\"<sha256>\"}"
}

Publish a new version and you publish a new manifest. Old versions stay retrievable for as long as any relay keeps the events — version control by event history.

The deploy loop#

For our 0xBridge project the entire deploy is three commands' worth of logic:

1. Hash every file (sha256sum).
2. PUT each blob to the Blossom server.
3. Build the manifest with fresh hashes, sign a kind-15128 event, publish to relays.

In practice: a 40-line Blossom stub server and a ~100-line Python signer cover the whole pipeline. Compare that to any CI/CD pipeline you have ever maintained.

Two verification steps are worth doing every deploy:

• Check the manifest on a relay before celebrating. Query by author + kind 15128 and confirm the event came back. Relays accept writes they later drop, and manifests are exactly the kind of low-priority event that gets lost on smaller relays.
• Fetch one blob back by hash through the gateway or the server directly. A signed manifest pointing at blobs that were never uploaded is the most silent failure in this stack.

The localhost gotcha (learn the hard way)#

Our first deploy: manifest signed, verified, accepted by four relays — and the gateway returned 404 "nsite not found".

The cause was one tag. We had been testing against a local Blossom server, so the manifest said:

["server", "http://127.0.0.1:8080"]

The gateway tried to fetch our blobs from its own localhost. Of course it found nothing. The manifest was valid, the signatures were fine, the deployment was logically perfect — and the site was unreachable because the one pointer to the storage backend pointed into a void.

Two lessons:

• The server tag is load-bearing. It is the only place the gateway learns where your files live. It must be a URL reachable from the public internet.
• Public Blossoms reject anonymous uploads. The big community servers require auth (usually a Nostr-signed upload event), which is why the quick path of "just upload to a public Blossom" often fails. Either run your own Blossom on a VPS (it is genuinely ~40 lines), or use one that permits open uploads.

Why this matters for privacy#

A static site hosted traditionally leaks plenty: registrar WHOIS, hosting account, TLS logs, geo-CDN logs. An nsite shrinks the surface:

• No account anywhere. The site is signed by a key you hold. Lose the key, someone else owns the site; keep the key, nobody can take the site down.
• Content addressing defeats silent edits. Every file hash is pinned in a signed manifest. A gateway cannot serve you altered content without failing the hash check.
• Relays can't rewrite history. Old manifests stay fetchable; you can prove what a page said at publish time.
• Portability is total. Point the server tag at a new Blossom, republish, done. No export/import, no lock-in.

The trade-offs are real, too: relays are slower than Cloudflare's edge, blob availability depends on the server tier you choose, and gateway URLs are ugly (a 63-character npub). This is not a replacement for sites that need global edge performance — it is a replacement for sovereignty.

Where nsites fit in the stack#

Think of it as the bottom layer of a Nostr-native web:

• nsite — static sites and apps (this article's subject)
• NIP-34 — git repositories announced as events (pairs naturally: your README can link your nsite)
• Hashtree-style storage — encrypted, content-addressed git on Blossom, same transport
• NIP-23 — long-form writing

All four share the same primitives: keypairs for identity, relays for discovery, content-addressed blobs for payload. Learn one and you have learned the pattern for all of them.

Checklist before your next deploy#

• server tag points to a public URL (not localhost)
• Every blob GET-verified by hash after upload
• Manifest re-fetched from at least one relay after publish
• Hashes regenerated — no stale manifest entries
• Signing key backed up; the npub is the domain, the nsec is the deed

Bottom line#

nsites turn "deploy a website" into "sign an event." That is the right direction of travel: fewer intermediaries, verifiable content, and a web you can hold in your own hands. The stack is young and rough — the localhost bug taught us that — but it works, it is simple, and unlike your registrar, it cannot wake up one morning and decide your site violates a policy.

Ship something.