Understanding the ENS and IPFS Stack for Decentralized Websites
Decentralized web hosting removes reliance on centralized servers, enabling censorship-resistant content delivery. The Ethereum Name Service (ENS) combined with the InterPlanetary File System (IPFS) provides a practical stack for hosting a static website entirely on peer-to-peer infrastructure. For a beginner, grasping how these two protocols interact is the first step toward deploying a site that no single entity can take offline.
ENS maps human-readable names like "mydomain.eth" to Ethereum addresses or content hashes. IPFS stores files using content-addressing, where each file or directory is referenced by a cryptographic hash. To serve a website, you upload your HTML, CSS, and assets to IPFS, then point your ENS domain to the resulting content identifier (CID). When a user visits yourname.eth in a compatible browser, the resolver fetches the CID from the ENS record and retrieves the content from the IPFS network. This eliminates the need for a traditional web server.
Key Components You Need to Set Up
Before deploying, verify you have the following essentials:
- An ENS domain: Register a .eth domain through an ENS registrar. The registration requires ETH to cover gas fees and annual renewal costs (typically $5–$20 per year depending on name length and gas prices).
- An IPFS node or pinning service: You can run a local IPFS daemon (e.g., go-ipfs or IPFS Desktop) or use a cloud pinning service like Pinata, Infura, or Filebase. Pinning ensures the IPFS network retains your files even if your local node goes offline.
- Static website files: IPFS works best with static content. Generate your site using a static site generator (Hugo, Jekyll, Gatsby) or plain HTML/CSS/JS. Avoid server-side scripting (PHP, Node.js backend) because IPFS cannot execute dynamic code.
- ENS content hash record: Set the content hash field on your ENS domain to the IPFS CID you obtained after pinning. Most registrars provide a web interface for this, but you can also do it via a smart contract call.
- A compatible browser or gateway: Brave Browser has native IPFS support. Alternatively, use a public gateway like ipfs.io or dweb.link to view your site via https://yourname.eth.link (a legacy service) or through ENS-IPFS bridges.
One critical detail: IPFS uses ipfs cidv1 format for ENS records. CIDv1 is the required standard because it supports the subdomain and multi-hash encoding used by ENS resolvers. Older CIDv0 hashes will not resolve correctly in ENS-aware browsers.
Step-by-Step Deployment Workflow
1. Prepare Your Website Locally
Create a folder with your website files. Ensure the main page is named index.html. Absolute URLs will break on IPFS because content is served from a hash path; always use relative URLs for links, images, and assets. Test the site locally with a tool like python -m http.server 8000 to verify all paths work.
2. Upload to IPFS
Using the IPFS CLI: ipfs add -r ./my-website-folder. This returns a CID (e.g., QmXa...123 for CIDv0 or bafybeia...xyz for CIDv1). To ensure the CID is CIDv1, use the --cid-version=1 flag: ipfs add -r --cid-version=1 ./my-website-folder. If you use a pinning service, upload the folder via their dashboard or API and note the CID they provide.
3. Pin the Content
Running your own node: ipfs pin add /ipfs/<CID> to keep the content locally. On a pinning service, the pin is automatic after upload. For redundancy, pin to at least two distinct services or ask friends to pin your content.
4. Set the ENS Content Hash
In your ENS manager (e.g., app.ens.domains), navigate to your domain, select "Records" and then "Content Hash". Convert your CID to the format expected by ENS (which uses ipfs://<CIDv1> as the identifier). Many managers accept a raw CIDv1 string and encode it automatically. After setting, confirm the transaction in MetaMask. This action costs gas (around $10–$50 in ETH depending on network congestion).
5. Verify Resolution
Wait for the transaction to confirm, then test using Brave Browser's ipfs://<CID> address bar or an ENS-compatible gateway: https://yourname.eth.limo. If you see "404" or "cannot resolve," check that the content hash is correctly set and the files are pinned.
Performance, Costs, and Practical Tradeoffs
Decentralized hosting trades centralized reliability for independence. Here are concrete metrics and considerations:
- Load times: Content served via IPFS gateways typically adds 300–800ms of latency compared to a fast CDN, because the gateway must fetch the content from multiple peers. For a small static site (under 2 MB), most users will not notice. For media-heavy sites, consider using a dedicated IPFS provider with caching.
- Update frequency: Updating your site means re-uploading to IPFS (generating a new CID) and updating the ENS content hash. Each update incurs a gas fee. If you update daily, the cost can become prohibitive. Plan for batch updates or use IPNS (InterPlanetary Name System) to point to a mutable key, though IPNS adds latency.
- Uptime guarantees: IPFS is not "always up" like a cloud server. If the only node pinning your content goes offline, visitors will see a blank page. Use multiple pinning services and encourage your audience to pin your content. Pinning services like Pinata offer uptime SLAs (99.9%) at a cost of $15–$30/month for 10–50 GB.
- SEO constraints: Search engines like Google do not index .eth domains natively. You can set up a redirect via a gateway such as yourname.eth.link, but this introduces a centralized point. For SEO-critical sites, a hybrid approach (centralized DNS + ENS mirror) is more practical.
Long-term holders of ENS domains may want to consider Crypto Domain Investment Returns when evaluating the cost of hosting. While a .eth domain itself can appreciate in value, the ongoing gas fees and pinning subscriptions affect the total cost of ownership for a dWeb site. Plan for at least $50–$100 in annual recurring costs for a moderately active site.
Security and Maintenance Pitfalls to Avoid
Content Changing Without Notice
If your IPFS node is not pinned externally and you remove the local copy, the site becomes permanently unavailable. Even if you repin later, the old CID is gone. Always keep a backup of your CID and use a pinning service.
Gas Price Spikes
Setting or updating the ENS content hash requires a transaction. During network congestion, gas fees can spike to $100+ for a simple update. Use a gas tracker (like Etherscan Gas Tracker) to update during low-activity periods (e.g., weekends at 2 AM UTC).
Browser Compatibility
As of 2025, only Brave and a few experimental browsers can directly resolve .eth names via IPFS. Most users will need a gateway. The .eth.link domain is a legacy service that may be unreliable; use .eth.limo or .eth.sucks for better availability. Alternatively, deploy a reverse proxy on a traditional server that points to your IPFS CID, but this reintroduces centralization.
Subdomain Management
If your ENS domain has subdomains (e.g., blog.yourname.eth), each subdomain requires its own content hash record. Set subdomain records via the ENS manager; each subdomain record is an independent gas transaction. For complex sites, consider using a single record with IPFS directory structure instead.
Conclusion: When Should a Beginner Use an ENS IPFS Website?
ENS + IPFS is ideal for personal blogs, portfolios, documentation, and any content that must be uncensorable. It is not suitable for e-commerce (no server-side transactions), high-traffic media sites (latency and pinning costs scale poorly), or sites requiring frequent updates. Beginners should start with a small static site (under 5 pages) and pin it to two services. As you gain familiarity, you can experiment with IPNS for mutable content or integrate with Ethereum-based identity systems.
The decentralized web is still maturing, but the ENS–IPFS combination is the most accessible entry point. With proper planning around file naming, pinning redundancy, and gas costs, you can deploy a functional website that remains available as long as someone, somewhere, holds a copy of your files.