harvis
Jekyll

Deploy your Jekyll app

Jekyll is what GitHub Pages runs under the hood for plain Jekyll sites, and the output is identical either way: a self-contained _site folder of plain HTML. Point the CLI at it directly.

steps
  1. 01

    Build the site

    Run "bundle exec jekyll build" (plain "jekyll build" also works if you're not using Bundler). Jekyll converts your Markdown and layouts into static HTML in a "_site" folder.

  2. 02

    Skip serve mode

    "jekyll serve" starts a local dev server with live reload — it builds into "_site" too, but you want it stopped and a plain "build" run for a clean deploy.

  3. 03

    Deploy it

    Run "npx harvis deploy _site" from your project root. No config and no login for this first deploy — you get a live URL immediately, plus a private claim link to attach the site to a free account whenever you're ready.

Deploy Jekyll with one command

Build your project, then hand the output folder to harvis. No account needed for the first deploy — you'll get a live link and a private claim link to manage it later.

terminal
bundle exec jekyll build
npx harvis deploy _site

Prefer dragging files instead of a terminal? Build the project, then drop the output folder here and publish it the same way.

git hook

Deploy Jekyll on every git push

The command above is one you will run again after every change. A git hook runs it for you: this one already points at _site, the folder Jekyll builds into.

The folder holding the finished site. "." is the repo root, which is right for hand-written HTML; a static-site generator writes somewhere else.

pre-push fires on every branch and every remote, so a feature branch would publish over your live site. With this on, a push from anywhere else exits early and goes through untouched.

in your repo root
cat > .git/hooks/pre-push <<'EOF'
#!/bin/sh
set -e
bundle exec jekyll build
harvis deploy _site
EOF
chmod +x .git/hooks/pre-push

The options, the gotchas and how to share a hook with your team are on the git hook page.

Jekyll deploy questions

I already use GitHub Pages for this Jekyll site. Why deploy here too?

GitHub Pages ties the site to a GitHub repo and its own domain scheme. Deploying the same _site folder here with npx harvis gets you an independent live link in about two seconds — handy for previewing a branch or a client draft before it's ready to merge.

Does Jekyll's built-in Sass and asset pipeline still work?

Yes — Sass compiles to plain CSS as part of jekyll build, so by the time _site exists everything is already plain static files. Nothing about the deploy step needs to know Jekyll was involved.

Is deploying a Jekyll app to harvis actually free?

Yes, no card required. Free limits are 500 files and 50 MB per site, which covers a static Jekyll build with plenty of room. Published sites don't expire — they stay live until you delete them.

Can I use my own domain with the deployed Jekyll site?

Every site gets a free harvis.page address, and you can pick your own subdomain from the dashboard after claiming it — my-app.harvis.page instead of a random one. Pointing a domain you already own (like mystore.com) at the site isn't supported yet.

How is this different from deploying Jekyll to Vercel or Netlify?

Vercel and Netlify are built around connecting a Git repo and running your build on their servers, with a dashboard to configure it. harvis skips all of that: you build locally (or in your own CI), run one CLI command against the output folder, and get a link — no project setup, and no account needed until you want to keep the site.

other frameworks

Deploying something else?

The recipe is the same everywhere — build it, then npx harvis deploy the output.