I’ve migrated my site and blog to Jekyll and a new hosting provider.
Moving to Jekyll
Until recently I’ve been using Svbtle for my blog. Svbtle is great (and free). But I wanted to have my website and blog under the same domain.
So in effect, I planned to change my website to be a blog and have a homepage that would look like the current site.
Kicking the tires of Ghost
I initially tried out Ghost. I chose Ghost since I’d used it previously and found it nice to work with. Plus it seem like has a few JS technologies that I like behind it. Ember.js in particular I wanted to use.
Ghost’s installation and onboarding process is good. Ghost comes with ready-written posts that take you through the editor, publishing options, admin settings, and so on.
However, my blog wasn’t a good fit for Ghost. I didn’t want a database-backed site, and don’t need an administration application. I also wanted to deploy the site using Capistrano. I didn’t like using Ember to render my blog posts.
Taking the well travelled road with Jekyll
After playing with Ghost for a bit, I tried out Jekyll.
The thing I most like about Jekyll is how simple it is. It does a lot less than Ghost. I don’t need to think about a database, for example.
Jekyll doesn’t support email subscriptions out of the box, SEO tools, a WYSIWYG editor, roles and permissions, multi-language support, and many other powerful features that Ghost offers.
Jekyll lets me write articles offline from a text editor, and version control the content. I don’t need to worry about database backups, because the whole site is backed up to Github, and I also have all the content locally.
What I had been trying to do with Ghost was very simple with Jekyll. I got the reassuring feeling that I was on a well travelled path.
From dynos to droplets
This was due to price, and wanting to run a virtual machine rather than a dyno (Heroku application container).
Most importantly, I wanted my site to be up 24/7.
Before now, my website was on a free-tier Heroku dyno (thanks, Heroku!) but this meant it wouldn’t be ‘running hot’ all the time.
On Heroku, if the site wasn’t visited for a bit (which was usually the case), the free-tier dyno would ‘cool down’. Visitors would usually experience a really long load time while Heroku started up the application.
I had this nagging fear that a potential employer would load the site and laugh at how slowly it loaded. It looked like I couldn’t handle one concurrent connection per month. You get what you pay for.
I expect Heroku aren’t in a hurry to fix this, given it’s a big motivation to upgrade.
DigitalOcean, so cheap right now
Switching to a Heroku paid tier would have kept my site up 24/7. For $7 the problem would be solved.
The thing is, DigitalOcean has given me $50 credit since I’m enrolled on a postgrad course.
On DigitalOcean I can run the site for free for 10 months, and after that DigitalOcean will still be cheaper at $5/mo.
Switching to DigitalOcean meant I could host multiple applications on a single virtual machine (a droplet).
I could run a single application per dyno using Heroku. That’s $7 per month per application.
If I wanted to run a Ghost blog, Nginx, and another ruby on rails app, I’d need to use two (three?) dynos. It didn’t seem easy to run multiple applications on the same instance with Heroku.
On DigitalOcean, so long as you stay within 1GB memory, you pay $5 to run an unlimited number of things. From what I could see that was cheaper than AWS.
That was fantastic. I was concerned that my dumb games, like Numberwang, would need to be killed.
But, since I can use Nginx to proxy requests to various servers on a droplet, Numberwang can live on.
I might still use Heroku in future, but I see it as a prototyping tool. You get much more flexibility with a virtual machine than a Heroku dyno, and at a cheaper price.
I wanted to run a single command to update my blog.
I spent a good while configuring a Ghost blog on DigitalOcean to be able to do that. During this I ended up quitting and switched to using Jekyll. There is a lot of documentation for running Jekyll, so this was very easy to set up.
Using Capistrano to deploy the blog, I just
cap production deploy, and it replaces the static files for this blog
in a few seconds.