IPFS for your static site
For this post, we will assume that the user has some familiarity with IPFS and the underlying idea behind it. For background information on this technology please check out the following link:
IPFS Powers the Distributed Web
IPFS aims to surpass HTTP in order to build a better web for all of us. Today's web is inefficient and expensive HTTP…
When using IPFS to host your website, you will need to use relative links versus absolute ones in order to facilitate correct addressing. Let us see an example of why this is so.
A user wishing to access
/ipns/L6Q6m8NXRTmVMxkL5Rc77DvaaCA2QyQZ9iRyHjouRyjfaX/blog would result in the correct file being returned, however, should a link on the page back to the homepage use an absolute link such as
<a href="/" title="homepage">Take me home</a>, this would resolve to
/ instead of
/ipns/L6Q6m8NXRTmVMxkL5Rc77DvaaCA2QyQZ9iRyHjouRyjfaX which is what you would expect if you are used to hosting your website on a domain such as
All of your website content should be contained within a single folder with a standard
index.html entry file.
There are many ways to interact with IPFS, including using the built-in CLI, however, we endorse using ipfs-deploy which exposes
ipd on your command line to handle the deployment. Deployment becomes as simple as running
ipd in the root of your static site generator project, in which case it automatically searches for the appropriate folder name, such as
$ ipd public -O -C
√ Directory x82_test weighs 374.1 KiB.
√ Added and pinned to Infura with hash:
i QmZjjpcsD5YCP5sJsDU3M9yn6WVeuqLynrSbaMZcgRkXse (https://ipfs.infura.io/ipfs/QmZjjpcsD5YCP5sJsDU3M9yn6WVeuqLynrSbaMZcgRkXse/)
Once you have deployed your website to IPFS, those files are available so long as there is a host willing to share them. If you are willing to provide an always-on solution to provide access to these files there is no problem, however, those running static sites are usually not willing to have a compute host dedicated to providing these files. This is where pinning comes into play. An external service such as Infura, Pinata, Fission, etc, offers services to host these files so that there is always at least one seeder that a user can use to request these files.
ipd these pinning services are included by default.
Since IPFS generates a new hash-bashed address based on the content of the primary index page of our website, users of your website might have a stale version. This is a problem for any website that expects to be updated at some point in time. To circumvent this problem, IPFS uses the concept of DNSLink which allows us to use a DNS TXT record as a mutable resource to point to our immutable hash. Should we wish to host our website on say,
x82.io, we would create a TXT record as
_dnslink.x82.io at our subdomain. We would then populate the value of the record with the ipfs hash of our website, eg
When users of your site use an IPFS client, it will perform a DHT lookup, and should the initial request URI not match an acceptable hash regex, and will then perform a rewrite should it find an acceptable DNS record for the DNS link.
This process can be automated via CI/CD by taking the root hash and amending the _dnslink TXT record.