cargo-generate: Scaffold a Rust Project From Any Git Repository

What cargo-generate actually solves for Rust teams

Creating a new crate is easy. Creating the tenth crate that matches the conventions of the previous nine is not. Copying a sibling directory and renaming things by hand is the usual workaround, and it fails in predictable ways: a leftover crate name in Cargo.toml, a stale module path, a README that still describes the old project. cargo-generate exists to remove that manual step. The README describes it as a developer tool to help you get up and running quickly with a new Rust project by leveraging a pre-existing git repository as a template.

The audience is narrower than "all Rust developers". This is for people who already have a repository worth copying: a service skeleton with your logging and configuration wiring, a library layout with your CI files, a workspace with your lint settings. If you have nothing to copy, the tool has nothing to do. The value comes from the template, not from the generator.

How templating works: git clone, Liquid, and cargo-generate.toml

The mechanism is easier to reason about than the command line suggests. cargo-generate resolves a template location, fetches it as a git repository, and then renders its files into a new directory. The rendering is done with Liquid: the dependency list in Cargo.toml pins liquid, liquid-core, liquid-derive and liquid-lib at version 0.26, so placeholders follow Liquid syntax rather than a bespoke format.

Two other pieces of the architecture are visible from the repository. First, the git feature is on by default and pulls in gix and reqwest, which is what allows a template to be fetched from a remote URL; the README notes that library consumers who only generate from local templates can turn it off. Second, the repository ships a TEMPLATES.md at the top level and an example-templates/ directory, which is where the project keeps its own example templates rather than only in external repositories.

The prompt side is handled by dialoguer and the progress display by indicatif, both listed as dependencies. That tells you what the interactive experience is built from, but the README does not spell out the exact prompt sequence, so treat the first run as something to observe rather than something the README predicts.

Installing cargo-generate and generating a first project

The README gives two installation paths. The standard one uses Cargo itself, and the --locked flag is part of the documented command rather than an optional extra:

cargo install cargo-generate --locked

If you already use cargo-binstall, the README points at the faster route, which downloads a prebuilt binary instead of compiling:

cargo binstall cargo-generate

Once installed, the shortest invocation takes a GitHub shorthand. The README shows this form:

cargo generate username-on-github/mytemplate

The full URL form is also documented, and is what you need when the shorthand is ambiguous:

cargo generate --git https://github.com/username-on-github/mytemplate.git

Templates on other git platforms use a scheme prefix. The README lists gl: for GitLab, bb: for Bitbucket, sr: for SourceHut, and gh: for GitHub. The SourceHut form is worth reading twice because the URL it produces contains a tilde:

cargo generate sr:username-on-sourcehut/mytemplate

For the complete list of arguments and options, the README defers to cargo help generate. There is also a GitHub topic, cargo-generate, which the README names as one place to find templates. What you should see after a successful run is a new directory populated from the template, with Liquid placeholders replaced by the values you supplied.

Where cargo-generate is the wrong tool

The tool is bound to git as the transport for templates. That is the design, and it has consequences. If your organization distributes internal scaffolding through an artifact registry, a tarball on a shared drive, or a language-agnostic generator such as cookiecutter or Yeoman, cargo-generate does not meet you there. It also does not manage a project after creation. There is no update path described in the README: once a project is generated, it is an ordinary crate, and pulling later template changes into it is manual work. The README does not document rollback either, so a generation that goes wrong is cleaned up by deleting the directory, not by an undo command.

The other boundary is Rust. The name, the subcommand form and the dependency set all assume a Cargo project. Related searches include "Cargo generate python", which suggests people arrive expecting a general-purpose generator. What the README describes is a Rust project generator; nothing in it claims Python support, and the Liquid rendering is applied to files in the template, not to a Python packaging workflow.

One more practical point: the default build compiles gix and reqwest. On a slow machine or in a constrained CI image, that is a real cost, and it is the reason the README bothers to mention the opt-out for library consumers.

cargo-generate compared with a hand-rolled cargo new plus copy script

The obvious alternative is not another generator. It is a shell script that runs cargo new and then copies files from a reference directory. That approach has one advantage: no extra dependency, no Liquid syntax to learn, and no template metadata. It also has a failure mode that cargo-generate is built to avoid. A copy script renames what you remembered to rename; a template declares its placeholders once and applies them consistently across every file it renders.

The trade-off runs the other way too. A copy script can do arbitrary things, including running commands, touching external systems, or generating files that do not exist in the source. cargo-generate renders a repository into a directory. That constraint is what makes it predictable, and it is also why it will not replace a build-system generator.

If you want a different generator in the same family, the choice is usually between a git-repository-based template and a directory-based one. The difference is the fetch step: cargo-generate's default feature set includes the git transport, so a template can live in its own repository with its own history and be versioned independently of the projects that consume it. A directory-based generator gives you no such separation.

Maintenance, releases and what the licence allows

The repository is not archived, and the last push was on 2026-09-24. The release history shows v0.25.0 on 2026-09-18, v0.24.0 on 2026-08-31, and v0.23.14 on 2026-07-23, so the project has shipped three releases in roughly two months. The version in Cargo.toml is 0.25.0, matching the most recent tag. The presence of release-plz.toml and cliff.toml at the top level indicates the project automates release and changelog generation, which is consistent with that cadence.

Upgrade cost is the part worth thinking about before you commit. The Cargo.toml pins dependencies with tilde requirements, which allow patch updates within a minor version but not minor jumps. That is a conservative choice, and it means a major-version bump in something like gix is a deliberate act rather than an automatic one. If you depend on cargo-generate as a library, the same pinning applies to you, and the git feature is the piece most likely to drag in transitive churn.

On licensing: the README states the project is dual licensed under Apache-2.0 and MIT, at your option, and the repository carries LICENSE-APACHE and LICENSE-MIT. The contribution section states that any contribution intentionally submitted for inclusion is dual licensed the same way unless stated otherwise. That is the project's own statement; it is not legal advice, and if you redistribute binaries or embed the library, your own counsel should review how the dual licence interacts with your distribution.

Editorial conclusion

Adopt cargo-generate if your team already maintains a reference repository and wants new crates to start from it with consistent names and structure. Skip it if you only ever create throwaway crates, or if you need a template engine that is not Liquid, since the tool's placeholder syntax is Liquid and the guide is the only place the full placeholder list lives. Before rolling it out, verify three things: that cargo install cargo-generate --locked works against your toolchain, that the template repository you intend to use actually carries a cargo-generate.toml with the variables you need, and whether you can afford the git feature, because the default build pulls in gix and reqwest and library consumers who only generate from local templates can turn that feature off.

Frequently asked questions

Official sources

1. cargo-generate/cargo-generate on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases