# DNN Platform is a multi-site CMS built on .NET > DNN, formerly DotNetNuke, is an MIT licensed content management platform that installs once and runs many sites, with a React based admin experience, hundreds of REST endpoints, six bundled languages and an extension store. It is a long-lived product with a 10.x release line, and its build is a large solution with a Yarn and Lerna front end alongside the C# code. **dnnsoftware/Dnn.Platform** — DNN (formerly DotNetNuke) is the leading open source web content management platform (CMS) in the Microsoft ecosystem. - Repository: https://github.com/dnnsoftware/Dnn.Platform - Website: https://dnncommunity.org/ - Stars: 1,141 · Forks: 794 - Language: C# - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/dnnsoftware-dnn-platform ## One installation, many sites DNN is the project formerly known as DotNetNuke, and the project description calls it the leading open source web content management platform in the Microsoft ecosystem. It is used to build commercial websites, social intranets, community portals and partner extranets, according to the same description. The first feature in the built-in list sets the tone: single installation with multi-site capability. That is a different shape from most CMSes, where a site is a thing you install. Here one installation holds a platform, and sites are hosted inside it, each with its own content, users and theme, sharing the same deployment and the same administrative backbone. For an organisation running a public site, a partner portal and an internal intranet on the same stack, that is the reason to pick it. The rest of the feature list describes a mature product rather than a minimal one. There is file and folder management, static and dynamic localization with six languages out of the box, namely English, Dutch, French, German, Italian and Spanish, custom site templates and themes, and what the description calls cloud readiness with MS Azure compatibility. There are hundreds of REST APIs for site and content management, a client side stack described as CSS 3, HTML 5, jQuery and React, a drag and drop UI with a rich text editor for in-place editing, security roles, protected content, SEO tooling, a scheduler, SSL support, taxonomy and a site log. The scale figures in the description are the project's own claims, and they are worth repeating with that caveat. The platform has been downloaded more than eight million times, powers over 750,000 websites globally, and the community is described as having more than a million members. Thousands of free and commercial extensions, apps and skins are listed in the DNN Store, which is what makes extending a site fast and affordable according to the project. ## The admin screens are React apps in a Yarn workspace The repository layout tells you that the administration experience is a separate front end, and it is a large one. The `Dnn.AdminExperience/` directory holds the client side applications, and the root `package.json` lists them as Yarn workspaces under a Lerna monorepo. There are around two dozen of them, and their names map one to one onto the administration screens: `Users.Web`, `Roles.Web`, `Security.Web`, `Extensions.Web`, `Sites.Web`, `SiteGroups.Web`, `SiteSettings.Web`, `Themes.Web`, `Seo.Web`, `TaskScheduler.Web`, `Servers.Web`, `Licensing.Web`, `SiteImportExport.Web`, `Vocabularies.Web`, `Styles.Web`, `Prompt.Web`, `Pages.Web`, `Extensions.Web`, `AdminLogs.Web`, `Bundle.Web` and `BulkInstall.Web`. There are shared ones too, `Dnn.React.Common` for the common React pieces, and the ResourceManager module has its own web application under `DNN Platform/Modules/ResourceManager/ResourceManager.Web`. The front end build runs through Lerna, and the scripts are in the manifest. ```json "scripts": { "build": "lerna run build --stream", "debug": "lerna run debug --stream", "watch": "lerna run watch --stream", ``` So the front end is a monorepo of about thirty packages with a shared toolchain, built and watched through Lerna, with the outputs consumed by the platform. There is also a sample single page React application under `DNN Platform/Modules/Samples/Dnn.ContactList.SpaReact`, which is the reference for a module that ships its own React front end, and a `Dnn.ClientSide` package with its own type definitions under `DNN Platform/Dnn.ClientSide/types/dnn`. The practical consequence is that a DNN contributor is a .NET developer and a TypeScript developer, and the admin experience is where most of the front end work happens. ## Modules, the store, and how a site is extended Extensibility in DNN is by module. The documentation lists it as extensible through custom modules and through the many third party modules available in the DNN store, and the repository shows the shape of it. The `DNN Platform/` directory contains `Modules/` with named modules such as `ResourceManager` and `BulkInstall`, and `Skins/` with a skin named `Aperture`. A module is the unit of extension: a piece of content type, an administration page, or a functional addition to a site. The DNN Store is where third party modules are published, and the project description points at it as the reason extending a site is fast and affordable, since the alternative is writing modules from scratch for every capability a site needs. The file and folder management, the scheduler, the SEO tooling, the site log, the task scheduler and the licensing screens are all admin applications in their own right, which tells you how much of the administrative surface has been decomposed into separately deployable pieces rather than one monolithic admin page. There is also a bulk installation mechanism. The repository has a `DotNetNuke.BulkInstall.slnf` solution filter and a `DotNetNuke.BulkInstall/` directory, plus the `BulkInstall.Web` workspace and a `DotNetNuke.BulkInstall` module. That is the machinery for installing a set of modules and content into a fresh site, which is what makes it feasible to stand up a configured instance rather than a bare one. The theme system is the other half of the extension story. Custom site templates and themes are a built-in feature, and `Themes.Web` and `Styles.Web` are the admin apps that manage them. ## The build spans Cake, .NET and a Node front end Building DNN is not a single command, and the repository reflects that. The solution file is `DNN_Platform.sln` with a companion `DNN_Platform.sln.DotSettings`, and there is a central `Directory.Build.props` and `Directory.Packages.props` for the shared MSBuild configuration and central package versions. There is also `Directory.Packages.TestAndBuild.props` for the test and build specific package set. The build scripts are `build.sh` and `build.ps1`, so there is a path for Unix shells and one for Windows, and `cake.config` points at Cake as the build script tool. Continuous integration runs on Azure Pipelines through `azure-pipelines.yml`. Versioning is handled by GitVersion, with the configuration in `gitversion.yml` and the .NET SDK pinned by `global.json`, and the .NET and Node toolchain versions are pinned by `global.json` and `.node-version` respectively. The front end uses Yarn, with `.yarnrc.yml` and a `yarn.lock` at the root, and Lerna is the only dev dependency in the manifest, at version 10. Code style is enforced rather than left to preference. The repository carries a `stylecop.json` for StyleCop, an `.editorconfig`, and a `CODE_OF_CONDUCT.md`. Code quality is monitored with NDepend, which the README calls out with a badge, and there is a `DotNetNuke.Internal.SourceGenerators/` project for source generators, plus a `Packages/` directory for the package definitions. The contributor documentation in the `.github/` directory is unusually complete for a CMS: build instructions, pull request procedures, a versioning policy, a release schedule and the approvers group that reviews incoming changes. ## Releases are cut from a develop branch The default branch is `develop`, not `main` or `master`, and the recent tags show the shape of the release cycle. Version 10.4.0 was released on 2026-10-06, preceded by v10.4.0-rc3 on 2026-09-30 and v10.4.0-rc2 on 2026-09-18, so a single minor version went through several release candidates over a couple of weeks before the final tag. That pattern matters for anyone planning work. A feature or a fix that needs to ship will either go into the current release line or wait for the next one, and the release schedule and versioning policy documents in `.github/` are where that is spelled out. There is a separate `VERSIONING_POLICY.md` and a `RELEASE_SCHEDULE.md` alongside `PULL_REQUEST_PROCESS.md`, which is a sign that the project treats releases as a process with published rules rather than an ad hoc event. The repository is not archived and the last push was on 2026-10-19, days after the 10.4.0 tag, so the tree is receiving work against the next version. The licence is MIT, with a LICENSE file and a NOTICE.md at the root, and the project is supported by the.NET Foundation, which is also why contributors are required to abide by the.NET Foundation code of conduct in addition to the repository's own. There is a SECURITY.md as well, which is a file worth reading before you build a dependency on the platform. ## Where a CMS like this is the wrong answer DNN is a heavyweight answer to a specific shape of problem, and the wrong answer outside that shape. The clearest mismatch is the headless API case. A team that wants a content API for a mobile app, a set of microservices, or a static site generator is looking for content and delivery, and DNN gives them a database, an admin interface, a theme engine, a scheduler and a security model for authenticated users. The REST APIs exist and there are hundreds of them, but they are the management surface of a CMS rather than a purpose built content delivery API, and the platform still wants to be the application. The second mismatch is a team without a Microsoft stack. DNN is C# on .NET, it is built and extended through .NET modules, and the whole extension ecosystem is .NET. A shop that standardised on another stack inherits a second runtime it has to run, patch and monitor, and the module ecosystem gives them less than it would in a stack they already use. The third is organisational. A CMS is an application with a database, an admin UI and an upgrade path, and it needs an owner. The strength of the platform, that a content editor can drag a module onto a page and change the site without a deploy, is also the source of its cost, because somebody has to own the extensions, the security roles and the upgrade schedule. A site that a marketing team updates weekly is what it is for. The alternative worth naming is a static site generator plus a hosted content service, which gives a fast site and a simple editor with none of the platform, at the price of the multi-site capability, the portal features, the in-place editing and the module ecosystem that DNN already contains. ## Conclusion DNN suits a Microsoft stack team that needs several branded sites or portals from one installation, content editors rather than developers as the primary users, and a product that has existed long enough to have a large extension ecosystem. It is the wrong choice for a greenfield project that wants a small headless API, because the platform is a content management system with a database and an admin UI rather than a set of services. Check first which branch you are building from, since the default is develop, and read the versioning policy and release schedule in the .github directory before you plan work around a release date. ## FAQ ### What is DNN Platform and what is it for? DNN, formerly DotNetNuke, is an MIT licensed open source web content management platform in the Microsoft ecosystem. Its distinguishing feature is single installation with multi-site capability, so one deployment can host commercial sites, intranets, community portals or partner extranets. ### How is the DNN admin interface built? The admin screens are separate React applications under `Dnn.AdminExperience/ClientSide/`, wired together as Yarn workspaces and orchestrated with Lerna. The root package.json scripts run `lerna run build`, `lerna run debug` and `lerna run watch` across the workspace packages. ### How do I extend a DNN site? Through modules, either custom ones or the free and commercial ones listed in the DNN Store. The repository shows the shape of a module under `DNN Platform/Modules/`, and a bulk installation mechanism exists in `DotNetNuke.BulkInstall/` for installing a configured set of modules and content into a new site. ### What licence is DNN Platform under? MIT, with the LICENSE and NOTICE.md files at the root of the repository. The project is also supported by the .NET Foundation, and contributors are required to follow the .NET Foundation code of conduct in addition to the repository's own. ## Sources - [dnnsoftware/Dnn.Platform on GitHub](https://github.com/dnnsoftware/Dnn.Platform) - [License: MIT](https://github.com/dnnsoftware/Dnn.Platform/blob/develop/LICENSE) - [Project website](https://dnncommunity.org/) - [README](https://github.com/dnnsoftware/Dnn.Platform/blob/develop/README.md) - [Releases](https://github.com/dnnsoftware/Dnn.Platform/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dnnsoftware-dnn-platform