Project Inquiry
Published on

Exposing Environment Variables to Jekyll

I’ve previously written about Jekyll’s built-in support for JEKYLL_ENV, which you can use to influence your page’s build process based on the environment you are building for (staging, production, …). You can think about JEKYLL_ENV (referenced as jekyll.environment from Liquid templates) as analogous to RACK_ENV or RAILS_ENV.

This is well and good, but it doesn’t help you much if you want access to other environment variables in your templates. To accomplish this, you have to write a small Jekyll plugin to read the environment variables from Ruby’s ENV constant and expose them to your page’s site.config.

module Jekyll
  class EnvVariables < Generator
    def generate(site)
      site.config['env'] = {}
      ENV.each_pair { |k, v| site.config['env'][k] = v }

If you put this code in a *.rb file in your page’s _plugins directory, Jekyll automatically requires and executes it for you - no further action required. With this in place, your can now reference your environment variables as site.env.YOUR_ENV_VAR from your Liquid templates.


I’m currently building a new landing page for Backbone33. Naturally, the landing page links to Backbone33’s sign-in page, which is deployed on different URLs depending on the environment (staging, production, …). I don’t know (or rather, I don’t want to know) what the sign-in URL in production is going to be when developing the page. In fact, all details about Backbone33’s production environment are isolated in our CircleCI jobs, which are building and deploying everything.

In our CircleCI configuration we are essentially just exporting a bunch variables to expose all production details required to build the page:

$ export APP_SIGN_IN_URL=""
$ bundle exec jekyll build

From our landing page code, we are referencing these variables like:

<a href="{{ site.env.APP_SIGN_IN_URL }}" class="button">Sign In</a>

That’s it for today. Thanks for reading!

Software: Jekyll 3.8.3