There are numerous alternatives for blogging platforms and content management systems (CMS). The old school approach is to store the content in a database and render the content using templates on demand on every request. Wordpress is an example of this approach. However, there are many viable blogging and CMS tools which work on a completely different technical model. Tools like Hexo (for the Nodeists) and Jekyll (for the Rubyists) are based on the idea of generating the entire static content every time the content changes. I will cover many of the pros of static site generators in the following, but first I will share by blog setup.

Simple blogging using Git, Hexo, Nginx and Digital Ocean

My blogging platform is Hexo, a static site generator, which doesn’t require database or any other tool than plain files - all the content is stored as YAML files on disk. I can use my favorite text editor Atom and do all the writing offline. This allows me to keep the sources for the site and posts in Git hosted at So, now I have version control for my blog as well.

The Hexo-generated static site is rsynched over ssh to a Digital Ocean server, which is running Nginx to serve this blog. The rsync deployment is taken care by Hexo, all I need to do is to configure ssh keys and run npm dist, which executes hexo generate && hexo deploy. To make things even more simple, I could change Digital Ocean server to AWS S3 and serve that the site using S3’s website-feature. That would be very straight forward, because Hexo has an S3 website -plugin.

Static site is as robust as the bedrock

Static site generators work on the principle of generating all the site content in a single batch. The end result is a set of all the html, js and css and images that are needed to render the site. The site is generated once and then transferred to the web server, which only needs to serve static files. This means no database or any other runtime dependency that could easily be unavailable. Also, when using a static site generator, I am not at the mercy of a shaky internet connection, since I am not editing the blog via a browser on some remote site.

There is no need to serve blog entries from the database, because the content doesn’t change based on the blog reader’s actions. It is the same site and same articles on every single request. Anything dynamic - such as database and server side programming - adds only unnecessary runtime complexity in the context of blogging. This kind of complexity can lead to unexpected outages. But, when you only serve static content through a reliable web server, chances are quite high that things will not fall apart unexpectedly.

The performance of a site served from plain static content is of course very good because the operating system should take care of serving the files from memory.

Dynamic content can be integrated on client-side

If there is a need to add commenting to the blog, a service such as Disqus can be integrated on the client-side easily. Since the dynamic content is not integrated on the server, our setup remains still very robust. There are a few security risks related to this, but I can live with those since this is just a personal blog. Web analytics can be implemented using either client-side tools like Google Analytics or simply visualize access logs on server side using something as simple as AWStats.

For me, static site generators offer flexibility, power to choose the tools I want to use and the robustness of a bedrock. A happy blogging experience.