This turned out to be a bit of an adventure…

Gem install setup

By default ruby and rubygems are available, but the default gem install location is not writable from a user account. In order to work around this set up gem to install into your home directory:

export GEM_HOME=/home/private/gems
export GEM_PATH=/home/private/gems:/usr/local/lib/ruby/gems/1.8/
export PATH=$PATH:/home/private/gems/bin
export RB_USER_INSTALL='true'

Which I conveniently found the jekyll docs themselves:

Then on that shell install jekyll

gem install jekyll

In order to run the jekyll just installed it needs to be found in


This may be useful to prepend to your PATH for convenience.

In any case the next issue I came across was not having a valid javascript runtime.

/home/private/gems/gems/execjs-2.2.1/lib/execjs/runtimes.rb:51:in `autodetect': Could not find a JavaScript runtime.
See for a list of available runtimes. (ExecJS::RuntimeUnavailable)

After some cursory perusal it appeared installing node on NFS might be hard, but since the gem environment was all set up it made sense to use a ruby alternative. execjs was the rubygem complaining about not being able to find a runtime and on its github page serveral alteratives are listed: I went with therubyracer since it was recommended by the jekyll docs (see that helpful troubleshooting page again)

After installing therubyracer my local gem install did work, but I noticed as well the system provided jekyll executable (installed in the main gem directory) was also working. But there was a catch both jekyll binaries were broken again if I opened up a new session, most likely because the environmental variables exported above were lost.

Gem installing take 2

Persusing the literature a little further I came across this very helpful post installing custom gems on your hosted jekyll blog which outlined how to install gems in a more sustainable fashion, but within a users permissions. The key takeaway was to run

gem install therubyracer --user-install

which installed the gem in the user’s home directory but on the gem search path which can be checked by running

gem env

and looking for gem_path another neat tidbit from the article.

The next issue I ran across seemed similar:

/usr/local/lib/ruby/site_ruby/1.9/rubygems/dependency.rb:247:in `to_specs': Could not find kramdown (~> 1.0.2) amongst

Learning that ~> 1.0.2 meant between version 1.0.2 and 1.1 from this issue I simply applied a similar process to get the right version of kramdown

gem install kramdown --user-install -v 1.0.2

This went fine and I could tell I had progressed since I was now getting a new error from jekyll --version complaining about a different gem. This was no longer a path I wanted to go down.

New Approach

Putting it down and walking away for a bit allowed me to think about the problem I was facing with all these old versions of gems and of jekyll: why don’t I just get on the bleeding edge right? Then it occurred to me that NearlyFreeSpeech very kindly provides a smooth system for swapping out the version of FreeBSD you’re running. It’s quick and easy!

I upgraded twice from green (Stable/Default) to blue (Stable/Upcoming), and then to white (Beta/Current) in which jekyll ran by default without any of my messing tampering and it was great!


I am deploying this with git on All my files are available on github including the git hooks I use in a bare repo on the server (in the util folder). You can find a good post on setting that up here: