I previously wrote about my migration from GitHub to Forgejo. In that article, I didn’t mention GitHub Pages because it actually took me a while to migrate away from them. Not because Pages are unique in any way, but because they are so convenient. It’s basically just choosing an action from the marketplace to deploy your framework of choice (or using the legacy gh-pages branch method), and et voilà, you are building and hosting your app with the option to hook your custom domain. Not many services can offer this level of convenience.
Deciding on an alternative service
As a self-hosting geek, I considered deploying Coolify on my home server, but I unfortunately promised myself not to host anything critical on my home infrastructure (yet) as I don’t have a setup reliable enough to work with any SLAs, and I do use GitHub Pages for business. Cloudflare Pages are a great service, but I generally try to avoid Cloudflare nowadays as their increasing share of the market and their tendency to try and rewrite everything with AI 1 2 frightens me. And so I decided that while I work on an alternative service in my free time (stay tuned), I will trust Netlify to host my pages in the meanwhile.
Deploying to Netlify
In general, there isn’t much difference between how I use Netlify and GitHub pages. Netlify has a neat Forms feature to which I migrated a couple of my pages instead of using some other 3rd party form submission backend, but that’s the extent of it. The only real difference is the deployment process. Netlify has the option to deploy your branches as easily as GitHub does (or even easier, since you don’t have to add an action to your repo) as long as you use GitHub, GitLab or Bitbucket. Since I use Forgejo, however, this isn’t ideal. Fortunately, Netlify also exposes a deploy API that you can use to deploy your page. There are a few actions that use this API 3 4 but with the recent influx of security vulnerabilities in 3rd party dependendencies and the API being simple enough to build on top of, I decided to go ahead and create a deploy action myself just to use in my projects (and learn how does one write actions).
Building an action
First of all, I was surprised to learn that you can actually use other actions as a dependency of your action. I was under the impression previously that one needed to create a Dockerfile with all the dependencies rather than using actions/setup-python which I happily used right away to build my action. After declaring the inputs & outputs of your action, you can proceed to write the logic of your action. The inputs you declared in your action.yml can be passed to your program as an environment variable or a CLI argument, and you output stuff from your program by opening and writing to the stream in GITHUB_OUTPUT. Everything in-between is your business logic. Since my script is fairly simple, I didn’t run into any problems with the actions sandbox or environment restrictions (which I am sure there are plenty). What the script does is basically walk the build directory and gather SHA1 digests of each file. Uploading this to Netlify gives you a list of files that you need to upload. At the price of minor programming inconvenience, you get the option to only upload a diff of your changes, rather than the whole page again. The script is available here.
Summary
So far, I’m happy with the change. My usage is within the free plan of Netlify and the extra Forms functionality, as well as the basic analytics they supply in the free plan is quite nice to use. And I don’t feel very vendor locked in by any of it - I believe that as soon as I make my homelab more resilient and potentially write my own hosting platform, I can migrate again quite quickly.