Most people assume a website requires a hosting bill. That assumption is wrong. IPFS lets you publish a real, custom-domain website on a peer-to-peer network — for free.
If you have ever built a personal site, portfolio, or small project, you know the drill: pick a host, enter a card number, wait for the bill. It feels like the cost of doing business. It isn’t.
The InterPlanetary File System (IPFS) is a peer-to-peer protocol that lets you publish static websites without leasing space on anyone’s server. Your files live across a distributed network of nodes, addressed by their content rather than their location. This article walks you through building a site, publishing it to IPFS, and pointing a real domain at it — no hosting contract required.
Let’s see how we can achieve this:
How IPFS Works for Websites
Traditional hosting points a URL at a specific server. If that server goes down, your page goes with it. IPFS flips this centralized model to a peer-to-peer(P2P) model.
When you add a file to the IPFS network, it receives a Content Identifier (CID). This is a cryptographic hash derived from the file’s contents. Any node(peer) holding your file can serve it, so there is no single point of failure and no single bill to pay.
The trade-off is that IPFS only works with static sites — HTML, CSS, JavaScript, and assets like images or videos. Dynamic server-side languages like PHP or Python are not supported. For server-side functionality, you still need traditional infrastructure. If your project only runs on the frontend, then you’re good to work with IPFS.
Build Your Site
First, let’s set up a local IPFS node. You can follow this article on how to download and install one.
IPFS doesn’t care how you author your content. You can write plain HTML, use a static generator like Hugo or Eleventy, or even scaffold a React app — it’s all up to you.
Here is a minimal HTML file to get you started:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>My IPFS Site</title>
<link rel="stylesheet" href="./style.css" />
</head>
<body>
<h1>Hello from IPFS</h1>
</body>
</html>
Copy the content above and place it in a file named index.html. Now, open your IPFS node and navigate to the Files page. Next, click the Import button, choose the File option, and upload the index.html file created earlier.
After the upload, click on the three dots on the file and choose Share link.
That’s it. You should have a link that resembles this:
https://bafybeifkygjhioi37knmgvlpl5lnbxo6lphn76raedrvsskihcn4sfwguq.ipfs.dweb.link?filename=index.html
You can paste this link into the browser to view your deployed site. For the first time, it may take about a minute for it to load. You should then see a page like this:
The Redeployment Problem
Every time you change a file and re-import it, IPFS generates a brand-new CID. Anyone who bookmarked or linked to your old CID now hits a dead end. For a site you plan to update, this is a real problem.
IPFS solves this using IPNS (InterPlanetary Name System), which is a mutable naming system that always points to your latest CID. Think of it as a forwarding address: you publish once to an IPNS key, and it redirects to whatever CID you tell it to.
The IPFS documentation on IPNS explains more about how to generate and publish IPNS keys.
Keep Your Site Online: Three Approaches
Importing a folder into IPFS Desktop makes your content available from your machine. But when your laptop closes, so does your site. You have three options for keeping it live.
1. Self-Hosting
Self-hosting means running your own IPFS node continuously to keep your content available on the network. If you have a home server or a VPS, you can keep an IPFS node running there and pin your CID. Pinning means that your IPFS node permanently stores the imported data. By default, IPFS treats your uploads as temporary, so you have to make them permanent by pinning.
For production use, self-hosting may not be practical due to challenges associated with managing your infrastructure, e.g., during a downtime.
2. Pinning Service
Pinning services handle persistence for you by storing and serving your IPFS content on always-on infrastructure. After uploading your site, the service pins your CID.
Popular providers like Pinata and Filebase provide 1GB of free storage to try out their services. They typically offer APIs, dashboards, and SDKs for managing uploads and pins. This is the most common approach for developers who want reliability without maintaining infrastructure.
The trade-off is partial dependence on third-party services, though your data remains content-addressed and accessible across the IPFS network.
3. Automated Deployment via GitHub Actions
This approach integrates IPFS deployment into your CI/CD pipeline. Whenever you push changes to your repository, a workflow automatically builds your site and uploads it to IPFS using a pinning provider.
Using GitHub Actions, you can define workflows that trigger on commits, generate a new CID, and optionally update DNS records (e.g., via IPNS or DNSLink). This ensures your IPFS-hosted site stays in sync with your codebase without manual intervention.
Set up a Custom Domain
Sharing a raw gateway URL works, but ipfs.io/ipfs/Qm… is not something visitors will remember or trust. You can instead link your IPFS URL to standard domain names like example.com .
Log in to your domain registrar’s dashboard, find the domain’s redirect (or forwarding) settings, and point it to your IPFS gateway URL. Your users can now access the site using the domain name.
Conclusion
IPFS proves that hosting isn’t a requirement; it’s a choice. You can publish a real, custom-domain website with no hosting bill.
There are still some trade-offs, but the technology is improving. The decentralized web is the future.
Top comments (0)