Copier: render and update project templates from Git

The problem Copier solves: templates that keep changing after the first copy

Scaffolding tools are easy to write and hard to live with. A generator that copies a directory once gives you a working tree on day one, and then the template author fixes a bug in the CI config, and every project generated from that template keeps the old bug. Copier's README frames this as two separate goals: code scaffolding, which every template supports, and code lifecycle management, where the template evolves and consumers update their projects. The README is explicit that not all templates allow updating, which is the honest way to put it, because updating depends on choices the template author makes rather than on the tool alone.

The intended audiences are named in the README: template creators, described as programmers who repeat code too much, and template consumers, who want to start a project quickly or evolve it comfortably. That second audience is the interesting one. Copier is not aimed at a developer generating a throwaway script; it is aimed at an organisation with a shared baseline (a service skeleton, a library layout, a docs site) that has to move forward without regenerating everyone's repository by hand.

How Copier renders a template: copier.yml, Jinja files and the answers file

The mechanism is a directory tree plus a questionnaire. The README's quick start shows a template project containing a copier.yml at the root, a Git repository, a folder whose name is itself templated ({{project_name}}), a file with a templated name and a .jinja suffix, and a file named after {{_copier_conf.answers_file}} which also carries the .jinja suffix.

Questions live in copier.yml, each with a type and a help string:

project_name:
    type: str
    help: What is your project name?

module_name:
    type: str
    help: What is your Python module name?

File contents are rendered with Jinja. The README's example file {{module_name}}.py.jinja contains a single print statement that interpolates the answer:

print("Hello from {{ module_name }}!")

The third piece is the answers file. Its template body is a comment telling the reader the file is machine-managed, followed by a filter that serialises the answers to YAML:

# Changes here will be overwritten by Copier
{{ _copier_answers|to_nice_yaml -}}

That file is what makes updating possible. Copier records what was answered at generation time, so a later run against an evolved template can reuse those answers instead of interrogating the user again. The README notes that Copier can replace values in any kind of text file, so the output is not restricted to Python; the .jinja suffix is the marker that a file is a template rather than a literal copy. Directory and file names are templated too, which is how {{project_name}} becomes the real package directory.

Installing Copier and generating a first project

Copier is a Python package. The README lists the prerequisites as Python 3.10 or newer and Git 2.27 or newer, and pyproject.toml confirms requires-python >=3.10. For CLI use the README points at pipx or uv:

pipx install copier

uv tool install copier

If you want it as a library inside an existing environment, the README gives pip and conda instead:

pip install copier

conda install -c conda-forge copier

There is also a Homebrew formula for macOS and Linux:

brew install copier

Once installed, generating a project from a local template is one command with two positional arguments, template then destination:

copier copy path/to/project/template path/to/destination

Expect an interactive questionnaire built from your copier.yml entries, one prompt per question, with the help text you wrote shown alongside. When it finishes, the destination contains the rendered tree. The README also documents programmatic use, which matters if you generate projects from CI or from another tool. The same call accepts a Git URL, and gh: and gl: are shortcuts for github.com and gitlab.com respectively:

from copier import run_copy

run_copy("path/to/project/template", "path/to/destination")
run_copy("gh:copier-org/copier.git", "path/to/destination")

A first real use is to copy a template you already trust rather than writing one. The README points at the copier-template topic on GitHub for browsing public templates, which is the fastest way to see how other authors structure copier.yml before you commit to your own layout.

Where Copier gets in the way: overwrite behaviour and template-side prerequisites

The README states that Copier takes care of not overwriting existing files unless instructed to do so. That is the correct default and it is also the first thing that will confuse a new user, because running copy into a non-empty destination will not silently merge or replace; you have to decide what you want. The README does not spell out the flag for allowing overwrites in the excerpt available here, so treat that as documentation to check in the CLI help before you script it.

The larger limitation is on the template side. Updating is not a property Copier grants automatically; it depends on the template recording answers and on the template author keeping the questionnaire compatible over time. A template that omits the answers file snippet, or that renames questions between releases, breaks the update story in ways Copier cannot repair on its own. The README says plainly that not all templates allow updating, which is an admission that the feature is conditional.

There is also a hard environment constraint. Python 3.10 and Git 2.27 are minimums, not suggestions. On a locked-down build image with an older Git, Copier is simply unavailable, and because it is a Python tool, anyone who needs it must have a Python runtime they are allowed to install into. Teams that standardise on a single non-Python toolchain should weigh that before adopting it as the org-wide generator.

Copier against Cookiecutter: same starting point, different ending

Cookiecutter is the obvious comparison, and the repository itself carries the cookiecutter topic alongside copier-template. The difference is in what happens after generation. Cookiecutter is a one-shot renderer: you answer the prompts, you get a tree, and the relationship between template and project ends there. Copier's README describes the project as something that is usually generated and updated from a template, and the answers file exists precisely to make the second half of that sentence work.

That difference shows up in the template layout. A Cookiecutter template is a directory of Jinja files with a JSON config; a Copier template is a Git repository with a copier.yml, templated path names, and a machine-managed answers file committed into the generated project. The Copier approach asks more of the template author up front, which is why the README can say that simple templates evolve into complex ones as needed. If you only ever generate once and never look back, Cookiecutter's smaller surface area is a reasonable trade. If your template has consumers you cannot email, Copier is built for the problem you actually have.

Licence, maintenance and what upgrading Copier costs you

Copier is MIT licensed, stated in pyproject.toml as license = { text = "MIT" } and classified as OSI Approved :: MIT License. MIT is permissive: you can use it commercially, modify it, and ship it inside a larger product, provided the licence text and copyright notice travel with the distribution. It imposes no copyleft obligation on the templates you render, which matters if you generate proprietary project skeletons. This is a description of the licence text, not legal advice; have your own counsel read it if the generated output is part of a commercial deliverable.

On maintenance, the repository is not archived and the last push was on 2026-09-18, with v9.18.2 released on 2026-09-07 and v9.18.0 and v9.18.1 both released on 2026-09-01. The release cadence is recent and frequent. Note the version numbering: Copier is on 9.x, and the project has a CHANGELOG.md at the repository root, so pinning a version and reading that changelog is the practical upgrade path. Because Copier is a CLI that writes into other repositories, an upgrade can change how templates are rendered across every project that uses it; run copier against a scratch destination after bumping the version rather than pointing a new release at a live repository. The dependency list in pyproject.toml is broad (jinja2, pydantic, pyyaml, questionary, plumbum and others), so a major version bump is also a dependency-resolution event, not just a binary swap.

Editorial conclusion

Adopt Copier if you maintain a repository that many projects are generated from and you want template fixes to reach those projects later; the update path is the reason to pick it over a one-shot scaffolder. Skip it if your templates are throwaway, or if your team cannot standardise on Python 3.10 and Git 2.27 on every machine that runs it. Before committing, verify two things: that your template ships the answers file Jinja snippet shown in the README, because without it Copier has no recorded answers to replay during an update, and that your destination directory is empty or that you intend to pass the overwrite option, since the README states Copier avoids overwriting existing files unless instructed otherwise.

Frequently asked questions

Official sources

1. copier-org/copier on GitHub
2. License: MIT
3. Project website
4. README
5. Releases