NUKE is the AKEless build system for C#/.NET: an MIT-licensed build automation tool that lets .NET developers define their CI/CD pipelines as a regular console application instead of YAML, and it is aimed at C# teams who want the language and IDE tooling they already rely on to extend to their build scripts.

What it is

NUKE is a build automation system for the C#/.NET ecosystem. Rather than describing a pipeline in YAML or in a shell-based build script, developers write the pipeline as a normal console application, which means the entire build definition is ordinary C# that can be compiled, debugged, refactored, and formatted with a standard IDE. The project is distributed as the NuGet package nuke.common and is documented at nuke.build, with community support available through its Slack and Discord channels.

The concrete problem it solves is the disconnect between the C# developer experience and the tooling that surrounds CI/CD. The project's own pitch observes that many developers are reluctant to touch YAML files and build scripts because they lose code completion, ease of debugging, refactorings, and code formatting in the process. NUKE replaces that YAML-and-script layer with a regular .NET console application, so the build pipeline benefits from the same language features the rest of the codebase already enjoys. In addition, it addresses several recurring build-automation problems in one place: parameter injection, path separator abstraction, access to solution and project models, and build step sharing across repositories.

Key capabilities

• Build pipelines are written as a regular console application, permitting object-oriented programming instead of a declarative YAML file.
• Parameter injection is handled by the framework, removing the need for hand-rolled argument parsing inside build scripts.
• Path separator abstraction lets the same build logic run across operating systems without per-platform branching.
• Access to solution and project models allows build steps to read the structure of a .NET solution directly.
• Build step sharing across repositories makes common build logic reusable between separate projects.
• CI/CD configuration generation produces YAML and other formats, and can automatically parallelize build steps across multiple agents to optimize throughput.
• Distribution runs through the nuke.common NuGet package, with stable and pre-release versions both published on nuget.org.

Who uses it and how

• .NET teams whose pipelines currently live in YAML files and who want the same debugging, refactoring, and code completion they get in the rest of their C# work.
• Organizations running multi-agent CI, which rely on the generated configurations that automatically parallelize build steps across several agents.
• Teams that maintain build logic across more than one repository and need build step sharing rather than duplicated scripts.
• Projects building on multiple operating systems, where path separator abstraction removes a common class of platform-specific bugs.
• The project has accumulated several thousand stars and several hundred forks on GitHub, and discussion happens in its Slack and Discord communities.

Getting started

NUKE is installed as the NuGet package nuke.common, with stable and pre-release versions published on nuget.org; the documentation at nuke.build covers the introduction and setup.

How it compares

The available facts do not name any comparable or competing build tools, and no list of paid products that NUKE replaces is provided. On the evidence available, NUKE stands alone in this registry.

When to use it — and when not to

NUKE is a good fit for C#/.NET projects that want build logic to be first-class, compilable code with IDE support. It is a poor fit for teams outside the .NET ecosystem and for those who are content with plain YAML or shell scripts and do not want a compiled console application in their build path. One honest limitation is that the README excerpt is largely badges and an elevator pitch, so most substantive documentation lives off-site at nuke.build, and this registry entry cannot substitute for reading it.