ENS Website Hosting with IPFS: A Practical Workflow

To host a website using an ENS name, publish suitable site files to IPFS or another supported storage system, then set the name’s Content Hash record. ENS supplies the name-to-content pointer. The storage provider supplies the files, and an ENS-aware browser or gateway retrieves them.

Decide what you are publishing

A simple public profile or documentation site is a manageable starting point. Prepare a folder containing the built HTML, styles, scripts and assets. IPFS’s deployment guide requires static output served to the client. Uploading a WordPress database or PHP files does not make the WordPress application run on IPFS.

If an app needs a backend, identify that dependency separately. For a first release, use content that can be read without a private API, login or server process. Keep secrets and account exports out of the public build.

Publish a release and keep it available

1. Build the site and check its entry page, internal links and assets locally.
2. Upload the release directory through a chosen IPFS pinning service or your own node.
3. Record the resulting root CID, the content identifier for that release.
4. Retrieve the release through a suitable gateway and check the actual pages.
5. Confirm an ongoing pinning arrangement rather than relying on a temporary upload alone.

IPFS documents pinning as keeping content available for retrieval, with self-hosted and provider options. Review the service’s storage and gateway conditions, including whether its gateway serves HTML. A pinned object and a working public website URL are separate checks.

Set the Content Hash in the ENS App

With the wallet allowed to manage records, find the name in app.ens.domains. The documented path is Profile, Edit Profile, then Other and Content Hash. Enter the IPFS identifier, review the change and approve the matching Mainnet transaction. Reopen the record after confirmation.

A public resolver must support the record. For wrapped names, the Owner holds the management role; project-issued subnames use their issuer’s interface. If the edit is unavailable, investigate permissions and resolver support before repeating transactions.

Understand how readers reach the content

ENS documents eth.limo and eth.link as gateway routes. Native .eth access depends on the browser or integration. A standard HTTPS gateway URL and a bare .eth identifier are different entry points, so test the link you intend to share.

Adding a Content Hash is a separate task from setting a receiving address or choosing a wallet’s primary name. One successful task does not prove the others work.

Update the release deliberately

IPFS content identifiers change when the underlying content changes. For a direct CID-based deployment, publish and pin the revised build, test its new identifier, then update the ENS pointer. Keep the previous release available while you verify the new one.

Record the source version, root CID, pinning location, ENS change reference and public check. This turns an update into a reproducible operation. More advanced mutable naming arrangements exist, but are outside this direct-CID workflow.

Troubleshoot one layer at a time

Try an independent retrieval route before changing several settings. Save the exact URL, browser, expected release and observed error. ENS’s website help explains gateway errors and storage availability checks; IPFS’s deployment guide covers build and retrieval concerns.

Keep an accessible publishing plan

For a public publication, decide which stable URL you will promote and maintain. A gateway’s existence does not establish Google indexing, rankings or that every visitor can use native .eth access. Keep readable page titles, working navigation and a clear contact route in the site itself.

This guide is documentation-based. We have not pinned a release, changed an ENS record or verified a live IPFS deployment for this article.