New Site Hosting

Last night, I finally got all of the pieces together for hosting of this site. Here, I will summarize what solution I ended up going with, and a little about my future plans.

Static site

After convincing myself that Markdown is only terrible (instead of utterly terrible), and that it would be ok for short postings like I intend to make here. I got this site set up with Jekyll for static site generation.

There was a bit of a learning curve with Jekyll, largely because Ubuntu 17.04 has a fairly old version as a package. I eventually just removed it entirely, and set up bundle following the instructions at the Jekyll site.

The only thing not documented was to get gem to stop trying to install software in the system directory. I’m not sure why this concept is so difficult for these languages, but I’ve encountered the same problem with pip (which at least recently, now has a --user flag to install in one’s home directory). The rule should be simple, the language-specific tools need to leave the platforms directories alone. Regardless, all I had to do to make the rest of the instructions work is set:

export GEM_HOME=~/gems

in my startup script, and everything works. I can run Jekyll with:

bundle exec jekyll build

to build the static site (placed in a _site directory), or run

bundle exec jekyll serve

to serve up the pages locally.

Name service

Until very recently, I’ve been using Linode for my DNS. I’m mostly happy with it, except that I find it is a bit slow to propagate changes to its own nameservers. I also didn’t find widely available command line tools to modify records.

After some experimenting with AWS’s Route 53 DNS service, I decided to use them as my nameserver. The cost is $0.50 per month, which is cheaper than Linode. However, the Linode DNS requires that I pay for at least one host at Linode, which restricts my hosting to them.

I’m keeping my registration with Namecheap for now. I have 1.5 years left on what I paid, and their customer support was able to change my name servers, even though the changes made in the UI never seemed to apply.

As the expiration approaches, I will likely consider AWS for the registration as well. The price is competitive, and AWS doesn’t charge extra for privacy on the whois record.


I initially considered using GitHub Pages to host my site. This is still open as a possibility. My main reason for avoiding it is that it doesn’t support using HTTPS with a custom domain. There is a workaround using CloudFront to distribute the data. Amazon will provide certificates for sites coming from CloudFront, but the data is still transferred unencrypted between GitHub and CloudFront’s servers. It technically would make the hosting no longer free, but the access patterns of my website are low enough, that it would probably be less than the $0.01 billing threshold.

For now, I ended up going with S3 for the hosting. Setting it up was a little complicated, but once done, distributing is fairly easy (aws s3 sync). Again, my access patterns will probably keep this under $0.01 per month. It is a little hard to tell, because I also use S3 for backup purposes, and that access does cost a little.

Although S3 is a bit complex, the documentation is pretty good, and I was able to configure access permissions and such mostly by copying snippets of JSON off of samples, and making minor changes for my purposes.

Publishing flow

Now that things are setup, I go through roughly this process:

  1. On my Linux box, I create a new file davidborg/_posts/, copy and edit the header from another post, and then write the post.
  2. In another window, I run bundle exec jekyll serve, and fire up a web browser to preview the post.
  3. Edit/refresh until I’m happy with how the post looks.
  4. Commit the post to git.
  5. Run a script that does a jekyll build and uses the AWS tools to sync the data with the S3 bucket holding the website.
About David Brown
Software engineer and Jazz musician, currently living in the Denver, CO area.
comments powered by Disqus