Sites built using Jekyll can be deployed in a large number of ways due to the static nature of the generated output. A few of the most common deployment techniques are described below.
ProTip™: Use GitHub Pages for zero-hassle Jekyll hosting
GitHub Pages are powered by Jekyll behind the scenes, so if you’re looking for a zero-hassle, zero-cost solution, GitHub Pages are a great way to host your Jekyll-powered website for free.
Netlify provides Global CDN, Continuous Deployment, one click HTTPS and much more, providing developers the most robust toolset available for modern web projects, without added complexity. Netlify supports custom plugins for Jekyll and has a free plan for open source projects.
Read this Jekyll step-by-step guide to setup your Jekyll site on Netlify.
Aerobatic has custom domains, global CDN distribution, basic auth, CORS proxying, and a growing list of plugins all included.
Automating the deployment of a Jekyll site is simple. See their Jekyll docs for more details. Your built
_site folder is deployed to their highly-available, globally distributed hosting service.
Use Kickster for easy (automated) deploys to GitHub Pages when using unsupported plugins on GitHub Pages.
Kickster provides a basic Jekyll project setup packed with web best practises and useful optimization tools increasing your overall project quality. Kickster ships with automated and worry-free deployment scripts for GitHub Pages.
Setting up Kickster is very easy, just install the gem and you are good to go. More documentation can here found here. If you do not want to use the gem or start a new project you can just copy paste the deployment scripts for Travis CI or Circle CI.
Web hosting providers (FTP)
Just about any traditional web hosting provider will let you upload files to their servers over FTP. To upload a Jekyll site to a web host using FTP, simply run the
jekyll build command and copy the contents of the generated
_site folder to the root folder of your hosting account. This is most likely to be the
public_html folder on most hosting providers.
Self-managed web server
If you have direct access to the deployment web server, the process is essentially the same, except you might have other methods available to you (such as
scp, or even direct filesystem access) for transferring the files. Just remember to make sure the contents of the generated
_site folder get placed in the appropriate web root directory for your web server.
There are also a number of ways to easily automate the deployment of a Jekyll site. If you’ve got another method that isn’t listed below, we’d love it if you contributed so that everyone else can benefit too.
Git post-update hook
Git post-receive hook
To have a remote server handle the deploy for you every time you push changes using Git, you can create a user account which has all the public keys that are authorized to deploy in its
authorized_keys file. With that in place, setting up the post-receive hook is done as follows:
laptop$ ssh email@example.com server$ mkdir myrepo.git server$ cd myrepo.git server$ git --bare init server$ cp hooks/post-receive.sample hooks/post-receive server$ mkdir /var/www/myrepo
Next, add the following lines to hooks/post-receive and be sure Jekyll is installed on the server:
GIT_REPO=$HOME/myrepo.git TMP_GIT_CLONE=$HOME/tmp/myrepo GEMFILE=$TMP_GIT_CLONE/Gemfile PUBLIC_WWW=/var/www/myrepo git clone $GIT_REPO $TMP_GIT_CLONE BUNDLE_GEMFILE=$GEMFILE bundle install BUNDLE_GEMFILE=$GEMFILE bundle exec jekyll build -s $TMP_GIT_CLONE -d $PUBLIC_WWW rm -Rf $TMP_GIT_CLONE exit
Finally, run the following command on any users laptop that needs to be able to deploy using this hook:
laptops$ git remote add deploy firstname.lastname@example.org:~/myrepo.git
Deploying is now as easy as telling nginx or Apache to look at
/var/www/myrepo and running the following:
laptops$ git push deploy master
Git pre-push hook
Instead of deploying using server-side hooks, you can deploy using
pre-push client-side (executes on your desktop machine) git hook. Check here an example for Github Pages.
Static Publisher is another automated deployment option with a server listening for webhook posts, though it’s not tied to GitHub specifically. It has a one-click deploy to Heroku, it can watch multiple projects from one server, it has an easy to user admin interface and can publish to either S3 or to a git repository (e.g. gh-pages).
Once you’ve generated the
_site directory, you can easily scp its content using a
tasks/deploy shell script similar to this deploy script. You’d obviously
need to change the values to reflect your site’s details. There is even a
matching TextMate command that will help you run this script.
Once you’ve generated the
_site directory, you can easily rsync its content using a
tasks/deploy shell script similar to this deploy script here. You’d obviously need to change the values to reflect your site’s details.
Certificate-based authorization is another way to simplify the publishing process. It makes sense to restrict rsync access only to the directory which it is supposed to sync. This can be done using rrsync.
Step 1: Install rrsync to your home folder (server-side)
If it is not already installed by your host, you can do it yourself:
- Download rrsync
- Place it in the
binsubdirectory of your home folder (
- Make it executable (
Step 2: Set up certificate-based SSH access (server side)
This process is
described in several places online. What is different from the typical approach
is to put the restriction to certificate-based authorization in
~/.ssh/authorized_keys. Then, launch
rrsync and supply
it with the folder it shall have read-write access to:
command="$HOME/bin/rrsync <folder>",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa <cert>
<folder> is the path to your site. E.g.,
Step 3: Rsync (client-side)
deploy script to the site source folder:
#!/bin/sh rsync -crvz --rsh='ssh -p2222' --delete-after --delete-excluded <folder> <user>@<site>:
Command line parameters are:
--rsh=ssh -p2222— The port for SSH access. It is required if your host uses a different port than the default (e.g, HostGator)
<folder>— The name of the local output folder (defaults to
<user>— The username for your hosting account
<site>— Your hosting server
Using this setup, you might run the following command:
rsync -crvz --rsh='ssh -p2222' --delete-after --delete-excluded _site/ email@example.com:
Don’t forget the column
: after server name!
Step 4 (Optional): Exclude the transfer script from being copied to the output folder.
This step is recommended if you use these instructions to deploy your site. If
you put the
deploy script in the root folder of your project, Jekyll will
copy it to the output folder. This behavior can be changed in
Just add the following line:
# Do not copy these files to the output directory exclude: ["deploy"]
Alternatively, you can use an
rsync-exclude.txt file to control which files will be transferred to your server.
Now it’s possible to publish your website simply by running the
script. If your SSH certificate is passphrase-protected, you will be asked to enter it when the
Read this post on how to deploy to Heroku using Rack-Jekyll.
Jekyll-Admin for Rails
If you want to host your site in Amazon S3, you can do so by using the s3_website application. It will push your site to Amazon S3 where it can be served like any web server, dynamically scaling to almost unlimited traffic. This approach has the benefit of being about the cheapest hosting option available for low-volume blogs as you only pay for what you use.
If you’d like to deploy your site to an OpenShift gear, there’s a cartridge for that.