Using Github Pages as a Webserver
In the past couple of years, I’ve become a huge fan of Github pages.
Github pages is a service offered by Github (about which, more anon) that allows you to publish code via a Jekyll server.
There are several reasons why this is a great service:
- It is free
- You can point custom domains/URLs at it
- You can archive releases in Zenodo (and give them DOIs)
- Jekyll is a low-bandwidth, flat-pages server.
While “free” is probably something everybody can understand the advantage of the other points may not be obvious. So let me go briefly through them, starting at the bottom.
A low bandwidth server
Github pages uses Jekyll to serve out its webpages. Jekyll is a server that compiles and serves out static webpages. That is to say pages that are pre-made on the server before your browser accesses them.
This is not the place to get into the technical details of this, but a quick comparison to Wordpress may help clarify things. When you write a blog post in Wordpress — or Wix, or most other blogging apps — what you are really doing is creating a database record. The system records your content, your name, the keywords, etc., in a database and then, when a user comes to your site, it produces a dynamic version of your blog. That is to say if somebody points their browser to the “blog” page, your server builds what it sends to the reader on the fly. The list of blog posts is produced in essence by a database query (“display all blog records with a date equal to today or earlier”) which outputs on the user’s screen. And then when the user selects a blog, it is put together in much the same way: a database query grabs the content, puts it in a template and pushes it to the user’s screen.
Back when the web was first created, this isn’t how things worked. In those days, people built websites one page at a time (you can see my old site (1992-2004), where I did the same thing, here). You would code a page, including any links to other pages you might want to include.
This is what is known as a static site and it has some advantages and some disadvantages. The advantage is that it is extremely low bandwidth: a website coded this way consists simply of a single text file (an html file) with the actual coding and, perhaps, a stylesheet (which says how things should look). This is fast to download even on very low-bandwidth systems (such as you might have in infrastructure-poor countries).
The disadvantage is that every page you add to such a site needs to be integrated into all the other pages by hand. I.e. if you create a page “my teaching” to list all the courses you teach, then every time you add a course, you have to edit that page to link to it. If you forget, then the page is invisible to your site. The only way somebody can find it is if somebody Googles it (and Google has indexed it, which it probably has).
This is why systems like Wordpress were invented. In a dynamic blogging system, all you have to do is write your entries. You don’t have to update your pages, because they are generated using database queries. So if you have a page called “my teaching” and it is designed to be a list of all posts under the “courses” category, then every time you add a post to “courses” it will be included in the “teaching” page — because that page is generated from the database by the user every time they go to your site.
Jekyll operates somewhere between these two states. It works, in essence by doing the database search once, pre-building the website, and then converting it to a static set of pages. Like Wordpress, this means that you can write individual posts without having to manually update all your pages — they are updated automatically when you generate the site. But like a hand-made site, they pages pre-exist on your server: when a user comes they simply download the text files that are there, without having to query a database or wait of a site to be built.
You can archive releases
This brings us to the second advantage: you can archive releases. Github is a commercial platform: although it was developed to support work on Linux, it is owned by Microsoft and is offered, in essence, without guarantees. But the EU digital data repository Zenodo interoperates with Github and allows you to permanently archive releases.
This means that you can create a reproducible archive of your website every time you add something to it. Create a post; create and archive a release. If you ever want to refer to that specific version, Zenodo preserves the entire site as a zip file and gives it a DOI.
You can point custom domains to it
While the best archiving uses institutional domains, the most user friendly domains are custom: mygreatdomain.com. Github pages allows you to both eat your cake and have it: you can point a custom domain at your site, but also leave it available to an institutional one (and, of course, the zip-archived version in Zenodo).
A quick example to show you what I mean: https://dpodonnell.info is a new site I’ve built in Github pages to promote my popular writing. As long as I pay for that URL, it should be available.
But what if I stop paying for it? Well in this case nobody would care. But if they did, it is still also available from my (permanent) Github URL: https://caedmon5.github.io/dpodonnell. Currently that resolves to my custom domain; but if my custom domain stopped working, it would still serve out using the original URL.
It is free
Finally, Github pages is free. While you have to pay to point a domain at it, you don’t have to pay for hosting. And since if you do pay for hosting you have to continue to pay (or lose your website), that is a major advantage!
