It is an opinionated starting line for modern .NET
CleanArchitecture packages a set of architectural choices into a .NET solution template. Instead of deciding how to separate domain logic, application behavior, infrastructure, and the web edge from scratch, a team can create a shaped project and begin adapting it. The current main branch targets .NET 10.0, while named branches preserve templates for .NET 9.0 back through .NET Core 3.1. That makes the repository useful both as scaffolding and as a concrete statement about how its maintainers think enterprise ASP.NET Core applications should be organized.
The user-facing choices are practical rather than ornamental. The ca-sln command supports Angular, React, or no client framework, plus PostgreSQL, SQLite, or SQL Server. SQLite is the default, and the README says a container runtime is needed only for the other 2 database options. After generation, dotnet run --project .\src\AppHost starts the application through Aspire, whose dashboard exposes application URLs and logs. This is a sensible menu for teams that want one backend shape without forcing every product into the same frontend or database.
What happened when we ran it
Our run covered the npm project under src/Web/ClientApp at commit 97663a0. In a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM, installation succeeded in 51 seconds. It installed 895 packages and occupied 506 MB. The checkout itself contained 258 files, about 5,737 lines of source, and measured 1.1 MB, so the dependency footprint was far larger than the source being evaluated. Those figures describe our sandbox run, not a general performance benchmark.
The build did not pass. It exited with code 1 after 10 seconds while the prebuild task called npm run generate-api; the final log showed NSwag starting with runtime Net100. That output establishes where the visible failure occurred, but it does not establish why NSwag stopped, so blaming a missing SDK or a template defect would go beyond the evidence. The useful conclusion is narrower: the client build was not reproducible in this environment after a successful npm install.
The test command also failed to complete within the 900-second limit. Angular finished generating browser application bundles, Karma 6.4.4 started on port 9876, and its Chrome launcher reported that no Chrome binary existed on the platform. The log explicitly asked for the CHROME_BIN environment variable. This is an actionable environment requirement, but the measurement does not tell us which Chrome package or configuration the maintainers expect in a Debian container.
The npm audit found 0 known vulnerabilities, and the checkout had a tests directory plus 4 CI workflows, though no Dockerfile. Those automation signals are positive, but neither changes the failed build and test result.
The strongest feature is the useful set of boundaries
The template makes several choices that fit ordinary product work. ASP.NET Core 10 and Entity Framework Core 10 form the server and persistence base; Aspire handles local orchestration; MediatR, AutoMapper, and FluentValidation cover familiar application concerns. NUnit, Shouldly, Moq, and Respawn are listed for testing. Scalar supplies API documentation. A new team is therefore not just receiving folders, it gets a coherent toolchain whose parts address commands, mapping, validation, database access, tests, and API discovery.
Its flexibility is constrained in productive ways. There are exactly 3 frontend modes and 3 database providers exposed in the documented command, enough to cover several common deployments without turning generation into a questionnaire. API-only mode matters because it avoids shipping a SPA that a service does not need. Documented Architecture Decision Records are another strong point: they give maintainers a place to understand why a boundary exists before deleting it during the first refactor.
The rough edges appear at the toolchain seams
The biggest caution is that the simple README path hides a multi-runtime system. A frontend choice brings Node.js and hundreds of npm packages; API generation invokes NSwag with Net100; browser tests expect Chrome; PostgreSQL and SQL Server introduce an OCI-compatible runtime. Each dependency is reasonable alone, but together they make the real setup wider than dotnet new followed by dotnet run. Our 506 MB npm installation is a concrete reminder that this is not a tiny starter.
The template is also architectural policy, not neutral plumbing. MediatR, AutoMapper, FluentValidation, Aspire, and a layered solution all become choices your team must understand and maintain. For a small CRUD service, those abstractions may create more navigation and indirection than value. For an established organization, generated naming, boundaries, or test conventions may conflict with an existing platform standard. Evaluate one realistic feature end to end before declaring the template your company default.
Activity looks healthy, but cadence is not proven here
The repository shows 20,534 stars and 20 open issues, with its last push on 2026-09-07, only 2 days before this review. The latest supplied release is v10.8.0 from 2026-03-23. Taken together, recent source activity and a modest visible issue count argue against calling the project abandoned. However, one release date is not enough to calculate a release cadence, and star count measures attention rather than response quality or production success.
It belongs before product code, not around an existing system
In a real stack, CleanArchitecture fits at project inception. Use it to generate the service boundary, application layers, persistence choice, client shell, and local Aspire composition, then connect your own identity, observability, deployment, and domain rules. It is less attractive as a retrofit for a mature codebase because imposing 4 conceptual layers and new libraries can produce a long migration without immediate customer value.
The practical adoption test is a thin vertical slice on the exact combination you plan to ship, such as React with PostgreSQL or API-only with SQLite. Confirm generation, migrations, NSwag output, a production build, and browser or API tests in your own CI image. Our install passed in 51 seconds, but our build and test outcomes show why the template should earn trust in your environment. It is a strong blueprint, not a substitute for that verification.