# Cent: one folder for the community Nuclei templates > Cent is a Go tool that clones the community maintained Nuclei template sets, organises them into a single directory with the folder and repository structure you want, reports on what it collected, and cleans up invalid templates. It suits a tester who wants the whole community catalogue rather than the one official repository, and it is a local copy that you have to keep in step yourself. **xm1k3/cent** — Community edition nuclei templates, a simple tool that allows you to organize all the Nuclei templates offered by the community in one place - Repository: https://github.com/xm1k3/cent - Stars: 1,052 · Forks: 166 - Language: Go - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/xm1k3-cent ## What the tool does Cent is described as community edition Nuclei templates, a simple tool that allows you to organize all the Nuclei templates offered by the community in one place. The problem it solves is a small one that becomes large quickly. There is an official template repository, and then there are a great many community ones, each maintained by someone, each with its own folder structure, and each with its own idea of where a template belongs. Nuclei takes a template path and runs what it finds there. If you want more than one set, you end up with several clones and an argument about how to pass them all to the scanner. Cent resolves that by doing the cloning and the arranging, and by giving the result a shape you chose rather than the shape the repositories happen to have. The output is a directory that you then point Nuclei at, and the last step is documented plainly. Once cent has been configured correctly you can perform a scan with Nuclei, with the template directory passed in and a tag filter to narrow it. ``` nuclei -u https://example.com -t ./cent-nuclei-templates -tags cve nuclei -l urls.txt -t ./cent-nuclei-templates -tags cve ``` So Cent is not a scanner and does not compete with one. It is the directory preparation step, and it is deliberately small. ## Installing it and the first run Installation is a Go install of the versioned module path, or a download from the releases page. ```bash go install -v github.com/xm1k3/cent/v2@latest ``` The version suffix in the path is worth noticing, since the project is on its second major version and the module path carries it. After installation you run cent init, which initialises Cent with the configuration file, and the README links the file it uses as the reference for what that configuration looks like. The configuration lives at a path under your own configuration directory, and the default is named in the root flags as the config file under a cent directory. That order matters. Cent is a client of a list of repositories, and the list is configuration, not something built into the binary. A fresh installation therefore has nothing to clone until it is initialised, and the initialisation is what writes the repository list and the settings. The tool is written in Go and the module requires Go 1.24. The command line is built with cobra, configuration is read with viper, the tables in the output come from a table rendering library, the output is coloured, and the HTTP layer for checking repository availability uses a retryable client. The release artefacts are produced with GoReleaser, from a configuration in the repository root. ## The commands, and what each one is for There are six commands, and the table in the readme describes each in one line. The check command checks if the template repositories are still available, which sounds trivial and is not, because the community template landscape is full of repositories that get renamed, moved or deleted, and a clone step that fails halfway leaves you with a half collection and no idea which half. The init command writes the configuration file. The summary command prints a detailed summary of the Nuclei templates you have collected. The update command updates your repository, which is the one to run when you have edited the configuration to add or remove sources. The validate command validates the templates, and if a template is invalid it is deleted from the folder, which is a destructive default and worth knowing about before you point it at a collection you care about. And the version command prints the Cent version. Each command has its own help, and the usage section lists them all with the help flag, so a user who only wants to know what one command does can find out without reading the source. The root flags are what shape the behaviour of the clone and the organisation, and they are worth reading as a group because they are the whole configuration surface of the tool. There is the config file path, the path to save the templates with a default of a cent-nuclei-templates directory, the number of threads used when cloning repositories with a default of ten, the timeout in minutes for each git clone with a default of two, a console output switch, and the two flags that control organisation, keep folders and group by repository. ## The organisation flags, which are the point of the tool The default behaviour is a flat copy. With the keep folders flag, the internal folder structure of each repository is preserved, so the collection mirrors the layout of each source repository. ```bash cent -p cent-nuclei-templates -k ``` That produces a directory organised by category, with a folder for CVEs, a folder for vulnerabilities, and an others folder for the templates that had no subfolder in their source repository. The by repository flag then adds a second level, so you can see both the category and where the template came from. ```bash cent -p cent-nuclei-templates -k -r ``` The result nests the repository name above the category, with the project directory and then the user and repository name, and the others folder underneath for the uncategorised templates. Why this matters is not obvious until you have several thousand templates from a dozen repositories. A flat directory of files with names from a dozen naming conventions is hard to browse, hard to exclude from and impossible to reason about when a scan takes a long time and you want to know which set is slow. Grouping by category gives you a filter that maps to how you think about the problem, and grouping by repository as well gives you provenance, which is the thing you need when a template misbehaves and you want to know who to ask. The default output path means that a run with no arguments at all does the most obvious thing, which is to clone everything into a directory named after the tool. ## The summary command and what it tells you The summary command is the most interesting of the six, because it turns a pile of cloned files into information about the collection. ```bash # Display summary in table format cent summary # Display summary in JSON format cent summary --json ``` The table output has three parts. There is a metrics table with the total number of templates, the number of CVE templates, and the number of invalid and valid ones. There is a severity distribution table with the counts for critical, high, medium, low and info. And there is a table of the top tags. The example output shows the scale. Several thousand templates in the collection, a few thousand of them CVE templates, and a top tag list led by cve, then xss and wordpress, which tells you at a glance that this collection is mostly about known vulnerabilities in a particular content management system. There are search and limit options, so you can narrow the output to the tags you care about, and there is an update subcommand, either for the current path or for a path you give it, which is how the summary is refreshed after a collection changes. The JSON form carries the same data in a structure with a metrics object, a severity distribution object, a tags object and a last updated timestamp, and the timestamp matters, because a summary of a collection that was assembled three months ago is a description of something that no longer exists. ## Configuration, exclusions and the update path The configuration file is where the sources and the exclusions live, and the readme shows the shape of the exclusion lists. ```yaml exclude-dirs: - ... - dns - ... ``` The point of these lists is that they make the update cheap. The documentation says that once you have updated the configuration file by adding new folders, running the update command deletes the matching directories from the collection without cloning all the GitHub repositories again. ```bash cent update -p cent-nuclei-templates -d ``` And there is a matching flag for excluding individual files, for the case where one template in a repository is the problem. That is the design point of the tool, and it is a good one. A collection assembled from many repositories is expensive to rebuild, so anything that lets you change the result without re-cloning everything is what makes the tool usable at scale. The initialisation and the checking commands are the other half of the configuration story. You can initialise with the default configuration, initialise from a configuration file at a URL you give it, or overwrite an existing configuration. There is an init check subcommand to see whether a configuration file exists. And the check command verifies that all the template repositories are accessible, with a remove flag that drops the unreachable ones from the configuration, which is the practical way to deal with a repository that has been deleted. So the intended lifecycle is clear. Initialise once, clone, check periodically, update when you add sources, and validate the collection before you scan with it. ## The state of the project, and how it fits The releases tell a short story. The three most recent are 2.2.0 and 2.1.0, both on 2026-06-06, and 2.0.0 on 2025-08-23, and the last push to the repository was on the same day as the two June releases. So the project is on a version 2 line that was cut in 2025 and refined in 2026, and the activity is in the 2.1 to 2.2 range rather than in a 3.0. The alternative to Cent is worth stating plainly, because for many people it is the better answer. Nuclei can be pointed at a template directory, and if one official repository covers your needs, there is nothing to organise. There is also the option of cloning the community sets yourself and passing several paths, which is exactly the manual work Cent automates. Cent earns its place when the number of sources makes manual assembly tedious, when you want a single directory rather than a list of paths, when you want provenance per template, and when you want to know what is in the collection before you point a scanner at it. The summary command exists for that last reason, and it is the feature that turns a directory of files into something you can reason about. The costs are the ones you would expect from a tool that keeps a local copy. The collection is a snapshot and goes stale, the update is a manual step, and the validate command deletes what it considers invalid. The project is Apache-2.0 licensed, the code is Go with the standard command line and configuration libraries, and the readme is explicit that the tool is intended to be configured and then pointed at by Nuclei. ## Conclusion Adopt Cent if you run Nuclei regularly and want the community template sets in one place rather than pointing at one repository, because the tool handles the cloning, the folder layout and the housekeeping. Do not adopt it if one repository is enough, since the cost is a local copy of many repositories and a directory you have to update. Before you scan, run the validate command, because the documentation says an invalid template is deleted from the folder, and read the summary output, which tells you what is actually in the collection you are about to run. ## FAQ ### What is Cent? It is a Go tool that clones the community maintained Nuclei template sets and organises them into a single directory, so that a scanner can be pointed at one path instead of many. It also reports a summary of the collection and can delete templates that fail validation. ### How do I install Cent and set it up? Install it with go install -v github.com/xm1k3/cent/v2@latest, or download it from the releases page, and then run cent init, which writes the configuration file with the template sources and the settings. The configuration lives under your configuration directory. ### How do I keep the community Nuclei templates organised with Cent? Use the keep folders flag to preserve the category structure of each source repository, with templates that have no subfolder landing in an others folder, and add the group by repository flag to nest the source repository above the category. The path flag sets where the collection is written and defaults to a cent-nuclei-templates directory. ### What does the Cent summary command show? A table of metrics with the total, CVE, invalid and valid template counts, a severity distribution with the counts for critical, high, medium, low and info, and the top tags. It also has a JSON output form, options to limit the number of tags shown and to search for a term, and an update subcommand to refresh the summary after the collection changes. ## Sources - [Issues](https://github.com/xm1k3/cent/issues) - [License: Apache-2.0](https://github.com/xm1k3/cent/blob/main/LICENSE) - [README](https://github.com/xm1k3/cent/blob/main/README.md) - [Releases](https://github.com/xm1k3/cent/releases) - [xm1k3/cent on GitHub](https://github.com/xm1k3/cent) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xm1k3-cent