I’ve had apps on Heroku since 2009, but over the last year or so I’ve been deploying apps there more and more. With the advent of the Cedar stack, there’s less and less you can’t do. Compared to provisioning a virtual server, even with the help of moonshine, you can’t beat
heroku create --stack cedar: boom, you have a live site with backups, logging, release management and the running of migrations and asset compilation on deploy. In just another few minutes, you can have SSL, rotating database backups, NewRelic, HopToad, cron, DNS, monitoring, and myriad other addons.
When I switched my blog from Radiant CMS to Octopress, I wanted to keep the site on Heroku. It’s free under normal scenarios and if I ever get on HackerNews or Reddit, I just have to scale up my web processes and pay a bit to keep the site responsive. If I were to be so fortunate, I wouldn’t have to scramble to set up load balancing on Linode or even wait while my slice resized. Yay cloud!
The standard method for deploying Octopress to Heroku involves generating your site, checking in the generated contents (within the
public/ folder), and deploying to Heroku. As Matthew Manning noted, neither having to check in generated content nor having it generated on-the-fly is ideal. We really need to hook into Heroku’s build phase.
The Cedar stack lets you provide a buildpack for generating the app. It’s how the stack can support Node.js, Python, PHP, etc. I forked Manning’s buildpack and customized it for Octopress. Here’s what you need to do to deploy your Octopress site to Heroku:
Get your repository ready for Heroku
Heroku needs to see the
source directories, but they’re left out of the Heroku application slug unless you remove them from
echo '' > .slugignore
Pygments won’t work on Heroku—or at least I haven’t found a way—so let’s switch to a Pygments API hosted on Heroku.
pygments.rb from the Gemfile. You’ll then need to patch
plugins/pygments_code.rb, removing the require at the top and adding an API call instead of the Pygments library call in two places.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Rearrange your Gemfile
When Jekyll builds your site, it needs the gems in the development group, but it’s assumed you’re generating your site before deploying, so you won’t need them in production. Since we’re pushing the generation step to Heroku and it uses
bundle install --without development:test, it won’t have the gems it needs in the build phase. We’ll need to pull everything but
rb-fsevent out into the default group.
gem 'heroku' inside the development group. If you like, you can add
gem 'thin' to use thin for your server instead of WEBrick.
Your Gemfile should now look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Create the app on Heroku
heroku create --stack cedar --buildpack git://github.com/jgarber/heroku-buildpack-ruby-octopress.git git push heroku master
The site should build cleanly and should work at the app URL given. If not, look at the build output when you pushed to Heroku and also check
Let me know in the comments if it worked for you and feel free to fork the buildpack.
Update: Plain Jekyll supported by the buildpack as well.
Mat Schaffer added support for vanilla Jekyll sites as well. Very elegantly done.