Umbraco CMS: a .NET content management system you install with dotnet new

The problem Umbraco CMS solves, and who it is actually for

Umbraco is a content management system written in C# and built on ASP.NET Core. The README frames the mission as making Umbraco "friendly, simpler and social", and the practical reading of that is a CMS that ships as a NuGet package you add to a .NET application rather than as a separate product you host next to one. Editors get a backoffice interface for content. Developers get a normal .NET project where the same solution holds the site, the content models and any custom code.

That shapes the audience. If your organization already runs .NET services, Umbraco keeps content in the same build, deployment and dependency-management world as the rest of your stack. A team that writes C# daily will find the extension points familiar. A team that does not write C# will spend its time in the backoffice and depend on someone else for anything beyond configuration.

The project is free and open source under the MIT licence, so there is no per-seat cost to evaluate. The trade-off is that a free CMS still costs you the people who can run it.

How the architecture works: a .NET application with a backoffice on top

The repository layout makes the shape clear. There is a single solution file, umbraco.sln, with src/, templates/, tests/ and tools/ alongside it. Directory.Build.props and Directory.Packages.props centralize build and package-version settings across the solution, and global.json pins the SDK. This is a conventional large .NET monorepo, not a plugin host bolted onto a PHP runtime.

The README is explicit that the repository is not the installation path: "You should not run Umbraco from source code found here." The intended flow is to consume the released packages and extend them. That distinction matters when you estimate effort. Cloning the repository gets you the codebase the maintainers build and test; it does not get you a supported deployment.

Content modelling happens in the backoffice, where document types and data types define the shape of your content, and media types define assets. The .env.example file in the repository root hints at how the newer tooling talks to a running instance: it references a client ID, a client secret, a base URL and a list of tool collections covering data-type, document-type, document, media-type and media. Those are the same concepts an editor works with, exposed for programmatic access.

The release cadence is worth noting for planning. Three lines are published in parallel: 18.2.0 and 17.7.0 on 2026-09-17, and 13.16.2 on 2026-09-14. Running more than one line at once is normal for this project, so "the latest version" is not a single answer.

Installing Umbraco with the dotnet CLI and running it for the first time

The README gives the install path directly, and it works on Windows, Linux and macOS after you install the .NET Runtime and SDK. The documentation linked from the README, under fundamentals/setup/requirements, is where the specific SDK version is listed; check it there rather than assuming.

First, install the project templates. This is a one-time step per machine, and it pulls the templates from NuGet:

dotnet new install Umbraco.Templates

Then scaffold a project. The --name flag sets the project name and the folder it is created in:

dotnet new umbraco --name MyProject

Move into the generated folder and start the application:

cd MyProject
dotnet run

What you should see is a running ASP.NET Core application that serves the Umbraco backoffice. The README does not state the port or the first-run account setup, so read the install documentation page before you hand the URL to anyone. The README also points to a hosted backoffice preview at backofficepreview.umbraco.com, which runs from mock data and does not persist edits. Use it to look at the interface, not to evaluate your own content model.

For a first real task, open the backoffice and create a document type, then a content node based on it. That sequence is what the linked tutorials cover, and it is the shortest path to understanding whether the editing model fits how your organization publishes.

Where Umbraco is the wrong tool

The clearest limitation is the entry cost. The README's own contribution guidance says not to run Umbraco from the source in the repository, which means the practical starting point is a .NET project you own and deploy. Someone who wants a brochure site live today with no build pipeline and no hosting for a .NET application is better served elsewhere. The template gets you running locally in three commands; it does not get you to production.

The second constraint is the multi-line release structure. With 18.2.0, 17.7.0 and 13.16.2 all receiving releases within days of each other, an upgrade decision is a real decision, not a routine patch. You need to know which line your project targets and what the support expectations are for it. The README does not document upgrade or rollback procedures; that material lives in the documentation site.

Third, the README does not document a headless-only mode. The backoffice is presented as the centre of the product, and the README's framing is about delivering digital experiences through a CMS with an editing interface. If your requirement is a pure content API with no editorial UI, verify that the documented API surface meets it before you commit, because the README does not make that case for you.

Umbraco CMS compared with WordPress and with a headless CMS

The comparison people reach for is WordPress, and the difference is the runtime and the extension model. WordPress is PHP with a plugin ecosystem you install into the application. Umbraco is a .NET application you build and deploy, with extension points in C#. If your team writes C#, Umbraco removes the context switch; if your team writes PHP or nothing at all, WordPress removes the build step. Neither is a quality judgement, it is a question of which language your organization can staff and operate.

The second comparison is against headless CMS products, where the product is an API and the front end is entirely yours. Umbraco ships a backoffice, and the README treats that interface as a first-class part of the product, going as far as hosting a live preview of it. Choosing Umbraco means accepting that editorial experience as part of the deliverable. Choosing a headless product means building that experience yourself. The README does not document Umbraco's headless delivery in enough detail to claim parity, so treat that as something to confirm in the documentation rather than assume.

Maintenance, upgrade cost and the MIT licence

The repository is not archived and the last push was on 2026-09-22. Releases across three lines landed within the same week in September 2026. Whatever else that says, it does not describe an abandoned project.

The maintenance cost sits with you. Three supported lines mean an upgrade is a choice about which line to be on, and the README does not describe a migration path between them. Budget for reading the release notes for the line you run, and for testing content models after an upgrade, since document types and data types are configuration that lives in your database rather than in source control by default.

On licensing, the repository is MIT. That is a permissive licence, and it is a different arrangement from the commercial offerings that share the Umbraco name; the README links to umbraco.com, and the free CMS in this repository is the MIT-licensed part. Read LICENSE.md and NOTICES.txt in the repository root for the actual terms, and get your own advice on how the licence interacts with your distribution plans. Nothing here is legal advice.

One more cost item: the repository root contains a CLAUDE.md, an .mcp.json and an MCP.md, alongside an .env.example that configures a client ID, a client secret and a base URL. That is tooling for programmatic access to a running instance. It is a real surface to maintain if you adopt it, and the README does not cover it.

Editorial conclusion

Adopt Umbraco if your team already writes C# and wants content editing and application code in one .NET solution. Do not adopt it if you want a no-code site in an afternoon or a headless-only API with no backoffice. Before committing, verify the .NET SDK version the current documentation lists under setup requirements, and confirm which release line you will run, since 18.2.0, 17.7.0 and 13.16.2 are all published.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. umbraco/Umbraco-CMS on GitHub