IPFS websites

Your ethername can host a website. Set its contenthash record to an IPFS CID and the gateway we run serves it at:

https://yourname.ipfs.cc

Step by step

  1. Build your site. Any static site works: plain HTML, Astro, Hugo, whatever produces files in a folder.
  2. Add it to IPFS. Use any pinning service (Pinata, Filebase, Lighthouse, 4everland) or your own IPFS node. You will get a CID like bafybei…. Prefer CIDv1 (starts with baf), since a DNS label is case-insensitive and CIDv1 is the form gateways can put in a hostname.
  3. Set the contenthash. Open your name’s manage page, then Records, then Website, paste the CID, an ipfs://… URI, or the gateway link your pinning service gave you, and confirm the transaction. The site encodes it into the standard binary contenthash format for you. A contenthash holds a root CID, so a link pointing inside a pinned folder keeps its root and drops the rest.
  4. Visit https://yourname.ipfs.cc.

How the gateway works

The gateway is a small resolver that looks up your name’s contenthash directly from the contract and serves the content from IPFS. Your name is the single source of truth: update the contenthash and the site updates; nobody can serve different content under your name without your key.

Remember that the gateway is a convenience, not a dependency. The record onchain is what matters, and any IPFS-aware browser or gateway can resolve your content without it.

Subnames

A subname can hold a contenthash like any other name, and every IPFS-aware client resolves it. What it does not get is a ipfs.cc address, and the reason is TLS rather than policy.

A certificate can cover one level of subdomain. The wildcard behind alice.ipfs.cc cannot also cover shop.alice.ipfs.cc, because browsers accept exactly one wildcard label. Serving subnames would mean a certificate per parent name, issued on demand, which needs a server that terminates TLS itself rather than the edge worker the gateway runs on. It would also publish every participating name in Certificate Transparency logs.

We are not doing that for now. The alternative, serving a subname at alice.ipfs.cc/shop, is worse than it looks: a subname can belong to someone other than the parent owner, and a shared path means a shared origin, so both sites would share cookies, storage and scripts.

So a subname’s site is real and reachable, just not at a name we host. Set the contenthash and open it through any public gateway, or through a browser that speaks IPFS.

Keeping content alive

IPFS content stays retrievable only while at least one node pins it. Your contenthash record lives onchain for as long as your name stays registered, but the content behind the CID is your responsibility: keep it pinned with your provider of choice, or on your own node.