resume-template is a Jekyll theme that turns a config file into a GitHub Pages resume

The document is a layout file, not a page

This is a Jekyll site in the sense that Jekyll builds it, but the interesting part is a single file. Most of the content configuration will take place in the /_layouts/resume.html file, and you simply edit the markup there accordingly.

That single decision explains the whole shape of the repository. The top-level entries are the Jekyll conventions: _config.yml holds the site configuration, _layouts/ holds the page templates, _includes/ holds partials, _data/ holds data files the templates read, _sass/ and css/ hold the styles, _assets/ holds files that get processed, and _plugins/ holds Ruby plugins. Alongside them are index.html, favicon.png, images/, a Gemfile and Gemfile.lock for the Ruby dependencies, a CNAME file for the custom domain, a Dockerfile, and a .travis.yml from the continuous integration era.

For a resume, that is a slightly unusual amount of machinery, and the reason is that the template is a Jekyll site rather than a static HTML file. The advantage is that you get templating, so the same layout can render a section from a data file, and the disadvantage is that a reader who wants to change one line of a heading has to know where the layout lives.

The README's own summary is that this is a simple Jekyll and GitHub Pages powered resume template, and the repository description says the same. The primary language recorded for the repository is HTML, which is consistent with the layout being the place the work happens.

There is one more thing the repository carries that has nothing to do with the layout, and the README calls it out directly. The code and styles are licensed under the MIT license, but obviously you should not use the content of this demo repo in your own resume. A separate disclaimer notes that use of the Lisa M. Simpson image and name is under fair use for educational purposes, and that the project licence does not apply to that material. So the template is reusable and the placeholder content is not, which is the correct arrangement and worth reading before you publish.

Options live in _config.yml, and the README does not list them

Most of the basic customization will take place in the /_config.yml file, and the README introduces it with a list of customizations available via that file.

That list is a placeholder note to write the options out. So the file exists and is where the settings live, but the enumeration of the keys is not present in the text as published. For a reader, that means the actual configuration surface has to be read out of _config.yml in the fork rather than taken from the documentation, which is a small but real amount of work if you are trying to decide whether the template does what you need.

It is also a sign of the repository's age. The overall shape of a Jekyll site, the _config.yml options file, the _layouts directory with a resume.html, the Gemfile and the CNAME file, is a configuration style that has been stable for a decade, and the parts of the README that are thin are the parts that would have been updated by an actively documented project.

The editing advice is short and practical. You want to fork the repo to your own account, then clone it locally and customize, or use the GitHub web editor to customize. The second option is significant for the audience this template targets, because it means you can make the whole edit from a browser with no local Ruby, no bundler and no Jekyll, which is what makes the one-command local build below optional rather than required.

The content side is the layout file, and the options side is the config file. That division is the template's entire model, and a user who internalises it has understood everything the project does.

Locally it is three commands, and Docker is a mounted volume

The local development path is the standard Jekyll one and takes three steps after the clone.

bundle install
bundle exec jekyll serve

With that done you open your browser to localhost:4000 and the site is served with live rebuild, which is the part that matters when you are tweaking the layout and want to see the result immediately.

The Docker path exists for people who do not want to install Ruby, and the commands are the ones from the README.

docker image build -t resume-template .
docker run --rm --name resume-template -v "$PWD":/home/app --network host resume-template

The build uses the Dockerfile at the repository root, which is short.

FROM ruby:2.7

WORKDIR /home/app

COPY Gemfile* ./

RUN bundle install

COPY . .

CMD [ "bundle", "exec", "jekyll", "serve" ]

The two design points in that file are worth naming. The Gemfile is copied before the rest of the source and installed in its own layer, so that a change to the layout does not invalidate the dependency layer and force a reinstall. And the run command mounts the working directory over /home/app, which is the volume mount in the docker run line, so the container serves the files you are editing on the host rather than a copy taken at build time.

The network host flag is there because Jekyll serves on port 4000 and the mount plus host networking keeps the local URL the same in both setups, which is convenient.

One caveat is worth stating plainly. The base image is ruby:2.7, which is a Ruby version well past its support window, so the container build is a historical artefact rather than something to copy into a new project. For your own fork, moving the base image forward is a one-line change, but you may hit compatibility issues with the pinned Gemfile.lock, and that is the work you would be taking on.

Publishing is a branch name and a CNAME file

The deployment story is the simplest part of the project, and it is the part that makes this template a good fit for the audience it targets.

GitHub Pages will host this for free with your GitHub account, and the requirement is that you are using a gh-pages branch. The default branch of the repository is indeed gh-pages, so the arrangement is already set up for you. Once the fork is pushed, the site is automatically available at yourusername.github.io/resume-template, and the README notes that you can rename the repo to resume for your own use if you want it at yourusername.github.io/resume, which is a shorter URL and reads better on a business card.

For a custom domain, you add a CNAME file, and the CNAME file is already in the repository for the demo site, with the follow-up instructions pointing at the GitHub Help article on setting up a custom domain with GitHub Pages.

The whole deployment is therefore: fork, edit two files, push to the gh-pages branch, and the site is live. There is no build server, no custom domain configuration beyond a CNAME, and no hosting cost. For a resume, that is the correct amount of infrastructure, and it is a meaningful contrast with a hosted site builder that wants an account and a monthly plan for the same single page.

The catch is that the pipeline is the GitHub Pages Jekyll build, which is the one Jekyll build you do not control. The theme's local build and the published build can differ if the Gemfile pins a different Jekyll version than GitHub Pages runs, and the repository's .travis.yml is a leftover from when the project had its own CI rather than relying on Pages.

One theme, one release tag, and a decade of quiet

The project status is best read from the numbers rather than the promises. There is exactly one release listed, v1.0.0 from 2015-07-24. The repository is not archived, the default branch is gh-pages, and the last push was on 2026-08-31, so something is still being touched.

The README makes a promise about the future that the repository does not currently fulfil. Right now resume-template only has one theme, and more are coming, with a soon and a heart. A decade later, the theme count is still one.

That is not a criticism so much as a fact about the shape of the project, and it has a direct effect on how you should read the rest of the documentation. The parts that describe how to edit the template remain accurate, because the mechanism of a Jekyll site has not changed. The parts that describe what will arrive should be discounted, because they have been outstanding since 2015.

There is a roadmap, and it is linked to a GitHub Projects board, with feature suggestions to be filed as issues. The contributing instructions are the standard fork-and-pull-request flow with an issue first, and they explicitly include improving the dummy content as a contribution target, which is a nice signal about what the maintainer wants help with.

The honest summary is that this is a template that works, that its documentation is thin in exactly the places where a project expects to grow, and that the author is still around. For a single-page site, the age of the code is not a functional problem. The Jekyll version and the Ruby base image are the two things that age does affect.

The alternative is a single HTML file, and that is often enough

The honest alternative to this template is writing one HTML file and putting it on GitHub Pages yourself, which takes a similar amount of time and involves none of the Jekyll machinery.

The difference in approach is where the structure lives. In the template, the document has a template layer, a data layer and a stylesheet layer, and the content is expressed as markup inside a layout file. In the single file approach, the content, the structure and the styles are one artefact that you edit directly, and there is no build step, no Gemfile, no bundle install and no Ruby in your life.

For a resume, the trade is not really about features, because a resume does not need templating, data files or plugins. It is about how the document evolves. If you rewrite your resume every few years, the template saves you nothing, because you are replacing the content wholesale. If you keep one resume and add to it over years, the template's separation of configuration from content starts to pay, and so does having a stylesheet you can restyle without touching the content.

The other half of the alternative is the other common path, a resume hosted on a commercial builder or a hosted template marketplace. Those give you a design and a preview, and they take your data, your name and your contact details to a third party. A repository you fork and a static file on GitHub Pages is the opposite arrangement, and that is a real reason to pick a template in this shape over a hosted site.

Two practical warnings apply to either path. The demo content, including the Lisa M. Simpson image and name, is not yours to reuse, and the README says so directly. And a web resume is often read as a PDF by a system you do not control, so whatever you publish should also print cleanly, which is worth checking before you send the link to anyone.

Editorial conclusion

resume-template fits a developer who wants a hosted resume page in an afternoon, is comfortable editing HTML and YAML, and does not need a design system or a CMS. It does not fit someone who wants a maintained, multi-theme template, since the README promises more themes and the project has a single tagged release from 2015, and it does not suit a workflow that needs content versioning beyond a Git branch. Before using it, fork the repository, edit _config.yml and _layouts/resume.html, replace the demo content and the Lisa M. Simpson image, and print the result to PDF to check it survives a recruiter's printer.

Frequently asked questions

Official sources

1. jglovier/resume-template on GitHub
2. License: MIT
3. Project website
4. README
5. Releases