My website has been hosted on many platforms in the past, from Vercel, back when I had a website running Next.js, to DigitalOcean and Netlify. I stuck with DigitalOcean for a long while back when I decided that I wanted to have a static website. While DigitalOcean did cost money to use, I needed a server for some of the experiments I was running. Back when I got started with the IndieWeb, there were some Python scripts I wanted to run that required a server.
My needs have since changed. I now no longer have a particular need to run a server and that got me thinking: why am I using DigitalOcean and running a server if I do not need to use one? Is there a simpler way? After a bit of research, I stumbled onto GitHub pages. I have been aware of GitHub pages for a long time but the platform did not meet my needs for a while. Now that my site is static, I started to wonder if GitHub pages would work for me.
In my research, I came across the GitHub Actions feature. For those of you who do not know, GitHub Actions is continuous deployment system that lets you bring some software development workflows into GitHub itself. There is an Action for Jekyll pages, which really excited me because it made me think that I could run my blog on GitHub pages successfully. With some experimentation, I found this Action would let me build my blog and then host it on GitHub pages.
Why would I go to the trouble of changing hosting providers again? My blog is getting bigger. With every new post I write, there is a new image that gets added to my blog. There is also the markdown for the post I have written. This was fine back at the start when I only had a few posts. But my workflow involved using FTP to upload each blog post to my DigitalOcean web server. With each passing week, I noticed it took longer to upload my blog to the FTP server, and it got to the point where I was not comfortable continuing on with that path.
To answer the question in the title of this post, this blog is hosted on GitHub pages. Here is my workflow for posting content on this blog:
Write a blog post in Typora, my markdown editor.
Paste the markdown from Typora into a new page in the _posts/ directory of my Jekyll project that powers my blog.
Format the document with the required front matter for the post title, categories, image, and layout.
Add any images to the /assets/ directory in my Jekyll project.
Create a commit with the new document and images.
Push the commit.
GitHub Actions runs and builds the blog.
The processed blog is then made available on jamesg.blog through GitHub Pages.
I did run into an issue where my blog project actually contained some other scripts and my Jekyll code was in a website/ directory. To fix this, I had to move the contents of my website/ directory into a new GitHub repository which is where I set up GitHub Pages. While I might have been able to build my page from website/, I could not find adequate documentation on how to do this. Also, the code in directories other than website/ was not required to run the blog—some of the code was scripts, other pieces of code were deprecated HTML documents—so just uploading the website/ directory into its own repository made sense.
I also ran into an issue where the default Jekyll GitHub Actions configuration built blog posts with a future date. This is a problem for me because I sometimes write blog posts which I publish on future dates. To fix this error, I went into the GitHub workflow file (/blob/master/.github/workflows/jekyll.yml on GitHub) and removed the --future flag, which added future posts to my blog. I also added the future: false attribute to my _config.yml file to give me more assurance that I would not post future posts on the blog again by accident.
GitHub Pages has been a pleasure to use so far. I now no longer think about all of the files I need to upload to my blog server via FTP. I just push a commit on GitHub and then Actions builds my blog using Jekyll. I do pay for GitHub Pro now so I am not exactly saving money. But I do have a more efficient workflow for writing blog posts, which matters a lot to me.