It is time to update again!

I think it is the hallmark of a proper engineer, when they spend more time on the underlying tech and hosting of their blog, than actually posting any content ;-)

What happened?

A couple years ago I moved my blog off centralised WordPress hosting, to fully embracing IPFS and the decentralised web. I use a combination of

  • Jekyll, to generate a static website
  • IPFS, to host the website data
  • ENS for decentralised lookup
  • Cloudflare, to provide a web 2.0 bridge (Allowing you to access via https://blog.davidburela.com)

To simplify building, publishing, and record updates, I had been using https://fleek.xyz/ as they had a free tier to get started. Which was fine as I only updated my blog every couple of months.

However Fleek changed their model and the cheapest tier is now $20/month! I am happy paying a couple dollars for hosting, but that is a big cost for a build pipeline…

What did I move to?

TL;DR GitHub actions! With 3 simple steps:

  • Build the Jekyll site
  • Publish to IPFS via Storacha
  • Update Cloudflare to point to the new hash

Building the site

GitHub Actions immediately detected the Jekyll project in the repo, and correctly provided a template that uses a docker image for the build.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Build the site in the jekyll/builder container
      run: |
        docker run \
        -v $:/srv/jekyll -v $/_site:/srv/jekyll/_site \
        jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future"

Publishing to IPFS

There is a GitHub action which will take the static website, and push it to Storacha who host it on IPFS. Storacha has a much better pricing scheme, and I’m happy to pay for the storage and serving.

https://github.com/ipshipyard/ipfs-deploy-action I just had to add the step to the action, provide some secrets, and it will publish and return the hash of my website.

    - uses: ipfs/ipfs-deploy-action@v1
      name: Deploy to IPFS
      id: deploy
      with:
        path-to-deploy: _site
        storacha-key: $
        storacha-proof: $
        github-token: $

Updating Cloudflare record

I am using the Cloudflare IPFS gateway to provide the Web 2.0 bridge to standard browsers. You point it at the hash of your website by updating a _dnslink TXT record, and your site is served up.

There is a dnslink update tool available https://github.com/ipshipyard/dnslink-action however it doesn’t work with Cloudflare gateways, as they lock the TXT record.

I ended up having to dive into the Cloudflare documentation, and find the API method required to interact directly with the gateway. https://developers.cloudflare.com/api/resources/web3/subresources/hostnames/methods/edit/

A bunch of messing around with auth keys later, I was able to update my action to do a PATCH call to update the record

    - name: Update DNSLink via Cloudflare API
      env:
        CLOUDFLARE_EMAIL: $
        CLOUDFLARE_API_KEY: $
        CLOUDFLARE_ZONE_ID: $
        CLOUDFLARE_IDENTIFIER: $
      run: |
        curl https://api.cloudflare.com/client/v4/zones/$CLOUDFLARE_ZONE_ID/web3/hostnames/$CLOUDFLARE_IDENTIFIER \
          -X PATCH \
          -H 'Content-Type: application/json' \
          -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
          -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
          -d '{"dnslink": "/ipfs/$"}'

How did it go?

I am really happy with the results.

  • Storacha serving is much faster than my previous hosts.
  • I now fully own my build pipeline.
  • I took the time to update a lot of Jekyll gem packages at the same time.

Will this result in more blog posts in the future…. probably. The previous setup had enough friction that it did put me off. This new setup is just write, commit, push.

Let’s see at the end of the year if it actually paid off ;-)