Orchard Core is an open-source, modular, multi-tenant application framework and content management system built on ASP.NET Core, for .NET teams that want to build or self-host modular web applications and content-driven sites under the BSD-3-Clause licence.

What it is

Orchard Core is two distinct projects shipped together. Orchard Core Framework is an application framework for building modular, multi-tenant applications on ASP.NET Core. Orchard Core CMS is a web content management system built on top of that framework, so the same modularity and tenant model that power the CMS are available to any application built on the framework underneath it. The repository is written in C#, sits in the Content & Publishing / Content Management Systems category, and carries the topic tags asp-net, c-sharp, cms, dotnet-core, modular, orchard-cms and orchardcore.

The concrete problem it solves is that .NET teams otherwise assemble a CMS, a module system and a multi-tenancy layer from separate parts. Orchard Core replaces that assembly work with one framework that already treats modules and tenants as first-class concepts, and with a CMS that is itself nothing more than a set of built-in modules on that framework. Teams that need several sites, brands or customers served from one deployed codebase, with features enabled per tenant, get that from the framework rather than from custom plumbing. The built-in module reference documents what ships in the box.

Key capabilities

• Orchard Core Framework: an application framework for modular, multi-tenant applications on ASP.NET Core.
• Orchard Core CMS: a web content management system built on top of the framework, distributed as NuGet package OrchardCore.Application.Cms.Targets.
• Multi-tenant hosting is a core framework concept, not an add-on.
• Built-in modules documented in the Reference of Built-in Modules at docs.orchardcore.net/en/latest/reference/.
• Two release channels: stable release/3.0 and nightly main, with current version v3.0.1.
• Nightly preview packages published to Cloudsmith under the orchardcore preview repository.
• Localization handled through the Crowdin project orchard-core.

Who uses it and how

• .NET shops building modular, multi-tenant applications on ASP.NET Core who want one deployed codebase serving many tenants.
• Content teams running Orchard Core CMS sites, enabled per tenant through the built-in module set.
• Teams serving large, mission-critical applications; upstream states v3.0.1 is production-ready and that no fundamental bugs or crucial missing features are known.
• Teams that track nightly main builds for unreleased improvements while stable work stays on release/3.0.
• Contributors and localizers working through the issue tracker, GitHub discussions, the Discord server and Crowdin.

Getting started

Start from the getting started documentation at docs.orchardcore.net/en/latest/getting-started/, and add the NuGet package OrchardCore.Application.Cms.Targets to a project. Anyone who wants to evaluate it as a user rather than a developer can follow the Test drive Orchard Core guide first.

How it compares

The provided facts list no paid or comparable products, and no peer CMS or framework is named. The topic tags reference only Orchard Core's own stack and its own name (orchard-cms, orchardcore), so on the evidence given it stands alone in this registry. Any comparison against other systems would have to come from outside the facts supplied here.

When to use it — and when not to

Choose it when the team already works in C# and ASP.NET Core, wants modularity and multi-tenancy as framework primitives, and is comfortable operating and upgrading a self-hosted ASP.NET Core application on either the stable release/3.0 channel or nightly main. Do not choose it for a turnkey hosted site or for a team without .NET skills, because the README assumes the reader will follow external getting started documentation rather than an in-repo quickstart, and support runs through Discord, GitHub discussions and an AI assistant rather than a vendor contract. The 854 open issues are the clearest honest signal that the project is large and actively churning; evaluate upgrade paths and the built-in module reference against your own requirements before committing.