Nuclei: A YAML Template Scanner for Teams That Want to Write Their Own Checks
Nuclei is a fast, customizable vulnerability scanner powered by the global security community and built on a simple YAML-based DSL, enabling collaboration to tackle trending vulnerabilities on the internet. It helps you find vulnerabilities in your applications, APIs, networks, DNS, and cloud configurations.
At a glance
- What is it?
- Nuclei is an MIT-licensed Go scanner that runs YAML templates across HTTP, DNS, TCP, SSL, WHOIS, JavaScript and Code protocols. Its real value is the template DSL and the community template library, not the binary on its own.
- Who is it for?
- Adopt Nuclei if you want to write your own checks as YAML and run them from a CLI or CI pipeline, and if you accept that the engine tracks a fast-moving template ecosystem. Do not adopt it if you need a managed, hosted scanning service with team workspaces and reporting, because the README points those users at the Pro and Enterprise editions instead.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Nuclei Solves: Detection Logic as a File, Not as a Plugin
Most scanners ship a fixed set of checks. When a new CVE lands, you wait for the vendor to ship an update, then you run it. Nuclei inverts that. The README describes it as a scanner built on "simple YAML-based templates" where you "design custom vulnerability detection scenarios that mimic real-world conditions." The template is the unit of work, and it is a text file you can diff, review and commit.
That matters for a specific kind of team. If you run a bug bounty programme, an internal red team, or a product security function that keeps re-checking the same classes of misconfiguration across many hosts, you do not want to file a feature request every time you need a new check. You want to write the check yourself, in an afternoon, and run it against a list of hosts. Nuclei is aimed at that workflow. It is a CLI tool first: the README states plainly that the project is "primarily built to be used as a standalone CLI tool."
The secondary audience is CI. The README lists integration into CI/CD pipelines "for vulnerability detection and regression testing" as a supported use. That framing is narrower than "run it everywhere." Regression testing implies a known set of templates run against a known set of targets on every build, which is a much more controlled scenario than open-ended internet scanning.
How the Template Engine Actually Executes a Check
A Nuclei template is a YAML document that declares an id, some metadata, and one or more requests. The engine reads the template, substitutes variables from the target and from any extracted values, sends the request over the protocol the template names, and then evaluates matchers against the response. Matchers are the decision layer: they decide whether the response counts as a finding. The README's claim of reducing false positives comes from this design, where a template can "simulate real-world steps to verify a vulnerability" rather than firing on a single string match.
The protocol list is the part that separates Nuclei from HTTP-only scanners. The README names TCP, DNS, HTTP, SSL, WHOIS, JavaScript and Code. Because the same template format covers all of them, a single scan can combine a DNS resolution check, a TLS certificate inspection and an HTTP request. The README also mentions "ultra-fast parallel scan processing and request clustering," which describes how the engine groups and dispatches work across targets rather than a per-host sequential loop.
Templates are not baked into the binary. The README links to a separate repository, projectdiscovery/nuclei-templates, and the cloud tier is described as giving access to "the latest Nuclei templates." That split is the architecture's most consequential detail: the engine and the detection content ship on different schedules. It also means the quality of any given scan depends on which templates you pulled and when, not on which version of the binary you installed.
Installing and Running Nuclei: The Commands the README Gives
The README points to the documentation site for installation rather than listing package commands inline, so the exact install line depends on your platform and is not reproduced here. What the README does show is the usage shape. There is a single target scan, a multiple targets scan, a network scan, and a scan with your own custom template. Those four are the documented entry points, and they map to the flag set described under Command Line Flags in the docs.
The custom template path is the one worth understanding before you install anything. You write a YAML file, and you point the scanner at it. That file is the artefact you version. If you are evaluating Nuclei for a CI pipeline, the practical question is not "does the binary run" but "can I pin template content the same way I pin a dependency." The README does not answer that question. It describes template access through the cloud tier and through the separate templates repository, and it does not document a lockfile or a checksum mechanism for template sets. Treat that as an open item to resolve during evaluation.
There is also a documented connection step: the README has a section titled "Connect Nuclei to ProjectDiscovery." The README lists integrations with Jira, Splunk, GitHub, Elastic and GitLab. Those are named as integration targets, not as bundled plugins with configuration snippets in the README, so the wiring detail lives in the docs site.
The README carries an explicit warning box that is easy to skim past. It says the project is in active development, that you should "expect breaking changes with releases," and that you should review the release changelog before updating. It separately warns that running nuclei as a service "may pose security risks" and recommends caution with additional security measures. Both statements are from the maintainers, and both should shape how you deploy it.
The Template Supply Chain Is the Real Maintenance Cost
The binary is a Go program under the MIT licence. You can vendor it, build it, and ship it inside a container. The recurring cost is not the binary. It is the templates.
Templates are contributed by the community, and the README frames this as a strength: detection content arrives quickly for trending vulnerabilities. The same property creates an operational problem. A template that worked last month can start producing noise after an upstream change, and a template you rely on can be edited by someone else. Because the templates live in a separate repository from the engine, an engine upgrade and a template update are two independent events, and the README's own compatibility warning covers only the engine side.
There is a second cost that the README implies without quantifying. It advertises "zero false positives" as a goal of the verification-style template design. That is a design intent, not a guarantee, and no scanner that sends live requests to live targets can promise it. Templates that perform multi-step verification reduce noise but do not eliminate it, and a template that mutates state on the target can do damage if pointed at production. The README's service warning is the closest it comes to acknowledging this.
The licence is MIT, which is permissive and places few obligations on how you redistribute or embed the tool. That applies to the engine repository as described here. It does not automatically extend to the separate templates repository, whose licence is not stated in the README, and it does not cover the cloud service. If you plan to redistribute template content, check the templates repository's own licence rather than assuming MIT carries over. This is a factual gap in the README, not legal advice.
Where Nuclei Is the Wrong Tool
Nuclei is a template runner. It does not crawl your application to discover endpoints, and the README does not describe a crawling or spidering capability. If your problem is "we do not know what our attack surface is," a template scanner assumes you already have a target list. You would need something else to produce that list first.
It is also a poor fit for deep application logic testing. Templates match on protocol-level responses. A flaw that requires a multi-step business workflow, session juggling across several roles, or reasoning about application state is not something a YAML matcher expresses well. The README's own framing, "simulate real-world steps to verify a vulnerability," describes short verification sequences, not full application test suites.
The README's service warning is a third boundary. If your instinct is to wrap the CLI in a long-running HTTP service and let other teams submit scans, the maintainers explicitly flag that as a risky pattern. That is not a hypothetical: an endpoint that accepts arbitrary templates and arbitrary targets is an execution surface. The README recommends additional security measures if you go that route, and it does not describe what those measures should be.
Finally, the active-development warning is a genuine adoption constraint. Expect breaking changes with releases is a direct quote from the README. Teams that cannot absorb periodic breakage in a security tool should weigh that before standardising on it.
The Alternative: Nessus, OpenVAS and the Fixed-Check Model
The closest comparison is a traditional vulnerability scanner such as OpenVAS or Nessus. The difference is not speed or protocol coverage. It is who writes the checks.
A traditional scanner ships a curated feed. The vendor or the project decides what gets checked, tests the check, and distributes it. You consume the feed and you get consistency: the same scan configuration produces comparable results across time and across hosts. You give up the ability to add a check yourself in an afternoon. If the check you need is not in the feed, you wait or you write a plugin against the scanner's own plugin API, which is a heavier commitment than editing a YAML file.
Nuclei inverts the trade. You get a low-friction authoring format and a community that adds content quickly. You give up the curation guarantee. Nobody has certified that a given community template is correct, that it will not produce noise on your stack, or that it will still behave the same next month. The README's "zero false positives" framing is a statement about what the template format makes possible, not a statement about what any particular template delivers.
A practical way to think about it: a traditional scanner is a subscription to someone else's judgement. Nuclei is a toolkit for exercising your own. If your team has nobody who will read and maintain YAML detection logic, the traditional model is the better fit, and adopting Nuclei will leave you running a community template set you do not understand.
Who Should Adopt Nuclei, and What to Check First
Adopt it if you have a defined target inventory, at least one engineer who will own template content, and a workflow where writing a custom check is a normal activity. The README's stated CI/CD use case, vulnerability detection and regression testing, is the strongest fit because the template set and target set are both bounded. Security teams doing recurring checks against owned infrastructure fit the same shape.
Do not adopt the open source CLI as your primary scanning platform if you need hosted multi-user scanning, executive reporting, SSO or compliance documentation. The README directs that audience to the Pro and Enterprise editions, which it describes as a cloud-hosted service built on top of the open source tool, listing features such as SAML SSO, SOC 2 compliance and cloud service integrations. That is a different product with different terms, and the README's feature list for it is marketing copy rather than documentation.
Before you commit, verify three things. First, how you will pin template content: the README does not document a lockfile or checksum for template sets, so decide whether you vendor a snapshot into your repository or accept whatever the current feed gives you. Second, what your scan actually sends. The README lists TCP, DNS, HTTP, SSL, WHOIS, JavaScript and Code as supported protocols, and a template using the Code protocol executes code, which is a meaningfully different risk profile from an HTTP GET. Third, the licence terms of the templates repository, since the MIT licence stated here covers the engine and the README does not state the templates' terms. None of those three is answered by the README, and all three determine whether the tool is safe to run in your environment.
Editorial conclusion
Adopt Nuclei if you want to write your own checks as YAML and run them from a CLI or CI pipeline, and if you accept that the engine tracks a fast-moving template ecosystem. Do not adopt it if you need a managed, hosted scanning service with team workspaces and reporting, because the README points those users at the Pro and Enterprise editions instead. Before committing, verify two things yourself: which template set and tags your scan actually pulls, and whether your target list is authorised for active scanning, since the README warns that running nuclei as a service may pose security risks.
Community notes