How my blog is hosted on IPFS with HUGO

Oct 10, 2025 min read

Why I use IPFS and HUGO for my blog

For this portfolio, my main requirement was to avoid using a traditional server to host it. I wanted to minimize the single point of failure (SPOF) and also reduce hosting costs.

Other options could have been static hosting services like GitLab Pages, Vercel, or Cloudflare Workers, which are easy to set up and reliable. But with those solutions, you lose the fun and the control that come with self-hosting your own portfolio.

At first, I tried to host the static files in an S3-compatible bucket using Garage, but that solution didn’t fully satisfy me — I wanted something more decentralized and resilient. That’s when I decided to give IPFS a try.

I built my portfolio with HUGO

I chose Hugo because it’s a fast, open-source static site generator written in Go. It’s lightweight, modular, and has an amazing community.

Hugo allows me to easily:

  • use or create themes,
  • integrate shortcodes and partials for modular content,
  • and automate the build with CI/CD pipelines.

With Hugo, I can write in Markdown, build my site in seconds, and deploy the static files directly to IPFS.

What is IPFS

IPFS stands for InterPlanetary File System. It’s an open-source, peer-to-peer protocol designed to make the web faster, safer, and more distributed.

Unlike HTTP, which relies on centralized servers and URLs, IPFS identifies content by its hash (CID) — not by its location. That means:

  • Any peer who has your content can serve it.
  • The network automatically deduplicates and caches data.
  • Your content can be replicated across hundreds of nodes, increasing redundancy and geographical distribution.

However, there’s a trade-off: if no one keeps (pins) your content, it can eventually disappear from the network. That’s why it’s important to have nodes that pin your data — either self-hosted or via a pinning service like Pinata or Web3.Storage.

How I host my portfolio

Now that I had my static site and chose IPFS, it was time to build and deploy the hosting setup.

Thanks to IPFS’s flexibility, I can use multiple machines in different locations to host the content. To automate everything, I built a CI pipeline that:

  1. Builds the Hugo site,
  2. Uploads the static files to IPFS,
  3. Updates the DNSLink on my domain to point to the new IPFS CID.

This way, every new commit or content update automatically propagates to the network.

How my infrastructure works

I currently run three IPFS nodes located in different places. They’re not part of a cluster, but they pin the same content, which ensures redundancy in case one node goes offline.

For the domain name, I use Cloudflare, which makes it easy to configure DNS for IPFS.

To make my domain resolve correctly, I use a DNSLink record. Here’s how it works:

  • When you upload content to IPFS, it generates a CID (Content Identifier).
  • The DNSLink maps your domain (for example, _dnslink.example.com) to that CID.
  • Your browser or IPFS gateway can then resolve example.com to the right IPFS resource.

If the user’s browser doesn’t have a built-in IPFS daemon, the request can go through a public IPFS gateway such as:

  • https://ipfs.io/ipfs/...
  • or https://cloudflare-ipfs.com/ipfs/...

For now, I use my own self-hosted IPFS gateway running inside Kubernetes, but in the future, I might switch to a hybrid model using both self-hosted and public gateways for better availability.

How I build and deploy my portfolio

The CI/CD workflow is fairly simple but powerful:

  1. Build stage: Hugo generates the static files from my Markdown posts and templates.

  2. Artifact stage: The build output is stored as an artifact in GitLab CI.

  3. Deploy stage: The artifact is uploaded to IPFS using the ipfs add -r command. Once uploaded, IPFS returns the new CID of the website.

  4. Update DNSLink: A script automatically updates the DNS TXT record on Cloudflare via API to point to the new CID. That means every new version of my blog is instantly available on the IPFS network, and mydomain.tld always points to the latest version.

What I’ve learned

This project taught me a lot about decentralized web hosting and how Web3 infrastructure can be used for something as simple as a blog.

It’s not the most practical or the easiest setup, but it’s a great learning experience. I like the idea that my website can live independently of a single server or provider — it’s a small step toward a more resilient internet.

Up to you

If you want to give IPFS a try and access this website directly through the network, you can install the IPFS Companion browser extension.

It integrates seamlessly with your browser and allows you to resolve IPFS links natively, without using a public gateway.

– Follow the official installation guide to get started.