Hosting a Website With Tor, ENS, and IPFS

Tor Onion Services, IPFS, and ENS solve different problems. An onion service provides a Tor-native address and connection path. IPFS addresses files by content. ENS can publish a content hash for compatible clients and gateways. Combining them adds alternatives, but it does not remove every operator, host, wallet, gateway, or availability dependency.

The earlier version of this guide treated the three layers as seizure-proof and attached fixed prices, provider guarantees, and browser-support claims to the design. Those claims are not supported by the reviewed protocol documentation and have been removed.

Start with a normal origin

Keep the primary application on a server that supports its actual runtime. Dynamic Next.js routes, server rendering, databases, and API handlers cannot be reconstructed from an IPFS directory. The origin can also publish the onion address and the current IPFS content identifier so readers can verify alternate paths.

Provider identity, payment, jurisdiction, logging, and takedown behavior require separate evidence. This guide does not label a hosting provider anonymous or resistant to legal process. The separate private-server comparison remains held while those claims are repaired.

Add a Tor Onion Service

The Tor Project's Onion Service setup guide configures a local web service and maps an Onion Service port to it. A minimal mapping for a local application on port 3000 is:

HiddenServiceDir /var/lib/tor/site/
HiddenServicePort 80 127.0.0.1:3000

After Tor reloads, the configured directory contains the generated hostname and key material. Read the hostname from that directory and test it with Tor Browser. Keep the application bound to localhost unless the clearnet deployment requires a separate public listener.

Onion Services avoid the public DNS and certificate-authority path for the onion address. They do not remove the host, Tor software, server logs, application vulnerabilities, or operational links between the onion service and other deployments.

Export only the static part of the site

Next.js documents static export through output: 'export'. During next build, compatible routes are rendered to HTML, CSS, JavaScript, and other static files. The official static-export guide lists supported and unsupported features.

const nextConfig = {
  output: 'export',
};

export default nextConfig;

Build the export and inspect the output before publishing it. A static mirror should not pretend that request-time APIs, authentication, mutable data, or server-only features still work. For a mixed application, publish a small static status or reference surface rather than a broken copy of the full product.

Install Kubo and add the export to IPFS

Current IPFS documentation names the Go implementation Kubo and provides binary, package, source, and container installation paths. The old npm install -g ipfs command in this article referred to a retired JavaScript package and has been removed.

After installing and starting Kubo, add the static directory with the current CLI. Record the returned content identifier. Rebuilding the site changes the content and normally produces a new identifier.

ipfs add --recursive out/

Pinning is the availability control

IPFS does not promise that every object remains stored forever. Its persistence documentation explains that nodes cache content and may delete unpinned data during garbage collection. Pin the site on infrastructure under the operator's control and, where needed, on additional independently administered nodes.

A public gateway is another access path, not proof of persistence. Gateway policies, caching, domain resolution, and local blocking can affect reachability even while a pinned copy still exists elsewhere.

Publish the IPFS content hash through ENS

ENS documentation describes decentralized website hosting by setting a name's content hash to an IPFS or other supported content identifier. The name owner submits the record update from the controlling wallet.

1. Verify the static export and pin its content identifier.
2. Open the ENS manager through a trusted path and confirm the wallet and network.
3. Set the content hash to the verified IPFS identifier.
4. Test with the exact client or gateway the intended audience will use.
5. Repeat the update after each release that changes the static content identifier.

Registration and transaction costs vary with name length, term, and network conditions. Client and gateway support also changes. This guide therefore does not state a fixed annual price, gas cost, native-browser list, or guarantee that a name cannot be suspended, transferred, compromised, or made unreachable through a particular access path.

Keep the layers independent enough to matter

• Store the Onion Service key separately from the ENS wallet seed.
• Do not place wallet secrets, Tor keys, and production credentials in the same deployment archive.
• Pin the IPFS export on more than one node when availability requires it.
• Publish checksums or release identifiers so mirrors can be compared with the intended build.
• Test the clearnet, onion, IPFS, and ENS paths separately after each change.
• Document which functions are absent from the static mirror.

The result is a set of alternate access paths with explicit limits. It is not a permanent or identity-free site. Each path needs its own key management, software maintenance, availability checks, and source-backed provider assessment.