jankapunkt/latexcv: a LaTeX CV and resume template collection with a Docker build path

What latexcv actually is, and who it is not for

latexcv is a set of eight CV and resume templates written in LaTeX, maintained by Jan Kuester. The README describes them as "self designed and self implemented and not copied from template collections", which matters if you have ever traced a popular template back to the same handful of originals. The layouts listed are Classic, Modern, Minimalistic, Two Columns, Sidebar, Sidebar Left, Row Layout, Infographics, and Infographics 2. Each lives in its own top-level directory (classic/, modern/, minimalistic/, two_column/, sidebar/, sidebarleft/, rows/, infographics/, infographics2/) and each contains a main.tex you edit.

The audience is narrow and specific. You need to be comfortable editing a .tex file, or willing to learn enough LaTeX to replace placeholder text without breaking the preamble. In exchange you get a PDF whose typography you control down to the point size, and a source file that diffs cleanly in git. If your workflow is a web form, a drag-and-drop builder, or a Word document you email to a recruiter, latexcv is the wrong shape of tool. The README's own framing is "Pick a template, replace the content, compile, done", which assumes you have a compile step at all.

The project is not archived, and the last push was on 2026-09-05. The README carries a repostatus badge pointing at the "Active" status, and the most recent release listed is minimalistic, dated 2025-02-05.

How the templates are structured and how a build flows

There is no custom document class here. Each template is a self-contained directory with a main.tex that pulls in whatever packages it needs, so the unit of work is the folder, not a shared style file you install. That is why the Docker build script takes a folder name as its argument: the folder name is the build target.

The build pipeline has three routes, and they converge on the same output. Overleaf compiles in the browser with no local install. The Docker route builds an image from the repository's Dockerfile, which is FROM ubuntu:jammy and installs texlive, texlive-base, texlive-latex-extra and texlive-fonts-extra via apt-get, sets WORKDIR /data and declares VOLUME ["/data"]. The manual route asks you to install a texlive distribution yourself, and the repository root contains a texlive.profile that the README says can be used "to install the minimum required texlive packages when manually installing texlive".

The README states that a minimal tex-live distribution is enough and that "No XeTeX, Koma or LuaTeX required." That is a real constraint in your favour: you are not chasing a heavier toolchain. The CJK support is the one place where the README claims a small footprint, saying setup is "only two lines of code" and pointing at docs/cjk/README.md. I have not read that file, and the README does not reproduce the two lines, so treat the claim as a pointer rather than a specification.

The docs/ directory is a VitePress site. package.json defines docs:dev, docs:build and docs:preview scripts against vitepress ^1.6.3, and the homepage is latexcv.pro. So the prose documentation is a separate build from the CVs themselves, and the two are not coupled.

Installing latexcv and compiling your first CV with Docker

The fastest reproducible path is the Docker one, because it removes the question of which texlive packages your machine happens to have. First clone or download the repository, then change into its top-level folder. The README provides a script for creating the image:

.docker/create_image.sh

That builds the image from the repository's Dockerfile, which installs texlive, texlive-base, texlive-latex-extra and texlive-fonts-extra on top of ubuntu:jammy. When it finishes you have an image you can reuse for every template.

To compile a specific template, pass its folder name. The README's example uses classic:

.docker/build.sh classic

The README states two constraints for this step: you need to be in the top-level folder of this project, and the image must already have been created. The script writes the compiled PDF into the template's folder, so after a successful run you should find classic/main.pdf alongside the source you edited.

If you are iterating repeatedly, the README offers a daemon mode that keeps a container alive and passes build commands through it:

.docker/daemon.sh
.docker/dbuild.sh classic
.docker/dbuild.sh modern

The daemon avoids paying container startup on every compile. The README credits this Docker approach to blang/latex-docker. If you would rather not run Docker at all, the manual route is to install a texlive distribution from latex-project.org or tug.org, or from your Linux distribution's repositories, and compile main.tex inside the template folder with your usual LaTeX command. The README does not spell out that command, so it is on you to know it.

Where latexcv stops being the right tool

The honest limitation is that latexcv gives you layouts, not content strategy. The README promises that you can "Give decision makers and HR only most important information about you in one single page or provide a complete and extensive full curriculum viate", but nothing in the repository enforces or checks that. A one-page constraint in LaTeX is a constraint you maintain by hand, and the moment your experience grows past the page, you are the one deleting lines.

The second limitation is the build itself. If you go the manual route, the README is explicit that it "just briefly describes the requirements and build procedure as there are many ways to install a LaTeX distribution on various OS" and invites you to open an issue if it is not helpful. That is a candid admission that the manual path is under-documented. The Docker path is better specified, but it requires Docker and it requires you to be in the top-level folder, which is easy to forget when you are deep inside a template directory.

Third, the CJK claim is the least verifiable part of the README. It says setup is two lines and links to docs/cjk/README.md, but the two lines are not shown in the README itself. If your CV is in Chinese, Japanese or Korean, budget time to read that file before you assume the templates will compile with your text.

Finally, nothing here generates a machine-readable resume. If a recruiter's system parses your PDF, the layout is your problem, not the project's. The README makes no ATS claim at all.

latexcv compared with Moderncv

The natural comparison is Moderncv, the long-standing LaTeX CV package. The difference is architectural. Moderncv is a document class: you call \documentclass{moderncv}, pick a style option, and the class defines the macros and the visual language for you. latexcv is a set of standalone documents: there is no class to install, no style option to switch, and each template's look is baked into its own main.tex.

That trade runs both ways. With a class, you get a consistent macro vocabulary and a single place to change your name, address and social links across every style. With latexcv, you get a template you can edit without understanding a class's internals, and you can diverge from it freely, because there is no upstream contract to honour. If you want to swap styles late in the process, a class is easier. If you want to bend one layout into something the author never intended, a standalone document is easier.

The README also notes that no XeTeX, Koma or LuaTeX is required. Moderncv users frequently end up on XeLaTeX for font selection, so the minimal-toolchain claim is a real point of difference rather than marketing. On the other hand, Moderncv has years of accumulated documentation and a large body of Stack Exchange answers; latexcv's guidance lives in the README, the in-code comments the README mentions, and the VitePress docs site. That difference in surrounding material matters more than the templates themselves once you hit an error you do not understand.

Maintenance, licence and what an upgrade costs you

The repository is not archived and the last push was on 2026-09-05, so the project is being touched. The release history is thin: the only release listed is minimalistic, dated 2025-02-05. That tells you the project does not version its templates in a way you can pin. If you fork a template and later want upstream fixes, there is no changelog per template to diff against; you compare files.

In practice that means your upgrade cost is a merge, not a package bump. The templates are plain .tex documents, so a fix to, say, the sidebar layout arrives as a commit to sidebar/main.tex and you decide whether to take it. If you have heavily customised that file, you will not take it. This is the normal cost of copying a template rather than depending on a class, and it is worth naming before you start.

The licence is MIT, which is permissive: you can use, modify and redistribute the templates, including commercially. The repository also carries CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md and a FUNDING.yml. I am not a lawyer and this is not legal advice; if you are packaging these templates into something you sell, read the LICENSE file yourself and check whether any bundled fonts or images carry their own terms, since the Dockerfile pulls texlive-fonts-extra.

Editorial conclusion

Adopt latexcv if you already write LaTeX or are willing to learn it, want a one-page or multi-page PDF CV, and prefer to own the source file rather than fill in a web form. Do not adopt it if you need an ATS-optimised plain-text pipeline, a visual editor, or a hosted service with version history; latexcv is files in a repository. Before you commit, verify three things: that your chosen template folder contains a main.tex you can compile with your texlive install, that the CJK setup documented under docs/cjk/README.md matches your target language, and that the Overleaf link for your template still resolves, since the README points to Overleaf as the lowest-friction path.

Frequently asked questions

Official sources

1. jankapunkt/latexcv on GitHub
2. License: MIT
3. Project website
4. README
5. Releases