Orchard Core

Last reviewed Aug 26, 2026 · 835 words

Pick Orchard Core for one reason: you need to run 5, 50 or 500 separate sites from a single ASP.NET Core process, each with its own database, users and theme, created from the admin UI in seconds. Nothing else in the self-hosted CMS space does multi-tenancy this natively. If you need one site, the same tool is a large, modular framework that will make you learn its content model, its Liquid templates and its module system before the home page renders, and that learning curve is why the catalogue rates it Hard rather than the Medium a single WordPress install earns.

Multi-tenancy is a first-class feature, not a plugin

A tenant in Orchard Core is a fully isolated site: its own content, users, roles, settings, enabled features and database (or its own table prefix in a shared one). The Tenants feature in the default tenant's admin creates a new one from a form with a URL prefix or a hostname, picks a database provider and a setup recipe, and the site is live at that address. The App_Data/Sites/{tenant} folder holds each tenant's settings and media.

This is the architecture an agency wants for client sites, a university wants for departments, or a SaaS wants for customer portals. It is also why the "steep learning curve" complaint exists: every concept in Orchard is scoped to a tenant, and single-site users pay the mental overhead without using the benefit.

Recipes decide what you get on first run

Orchard Core's setup screen asks for a recipe, and the choice matters more than it looks. The Blog recipe gives a working blog with a theme and sample posts. The Agency recipe is a marketing site. The Headless recipe enables the GraphQL and REST content APIs, the OpenID server for authentication, and no theme at all, for a front end you build elsewhere. There is a Bare recipe that starts empty. Recipes are JSON files that enable features, define content types and seed content, and you can write your own; an agency that spins up tenants from a custom recipe gets identical, pre-configured client sites every time.

Under the hood content is stored as documents in YesSql on top of SQLite, SQL Server, MySQL or PostgreSQL. SQLite is the default and adequate for a small site; for many tenants or heavy editing use PostgreSQL, since the Postgres for everything argument applies neatly here.

Running it takes .NET, not a LAMP stack

The project publishes a Docker image, orchardproject/orchardcore-cms-linux, listening on port 80 inside the container with App_Data on a volume:

docker run -d --name orchard -p 8080:80 \
  -v ./orchard-data:/app/App_Data \
  orchardproject/orchardcore-cms-linux:latest

That image is the stock CMS with the standard modules. The moment you want a custom module or theme, the image stops being the deployment and you are building your own .NET project that references the Orchard packages, which is the workflow the project actually expects. Budget the catalogue's 1,024 MB of RAM for the process itself; the .NET runtime is not small, and each tenant adds memory for its own caches once it has been hit. On a 4 GB VM, expect a few dozen lightly-used tenants before you feel it.

Put it behind a reverse proxy for TLS and set the forwarded-headers configuration, because Orchard generates absolute URLs and tenant matching by hostname depends on seeing the real Host header.

Where it sits against the other .NET and headless choices

Umbraco is the larger .NET CMS ecosystem, with more packages, more developers who know it, and a far better editor experience for a single content-heavy site; the catalogue's "smaller ecosystem than Umbraco" note is exactly right. Umbraco does not do multi-tenancy in the same isolated way. Against the JavaScript headless tools like Strapi or Directus, Orchard's headless mode is capable and includes an OpenID Connect server, but the developer pool is different: pick it if your team writes C#, and pick the others if it writes TypeScript. Against WordPress, the honest answer is that Orchard is a framework and WordPress is a product, and the CMS category has a dozen products between them.

What I'd do

If you are a .NET shop with more than a handful of sites to run, deploy Orchard Core as your own project on PostgreSQL behind Caddy, write one custom recipe that encodes your standard site, and create every new site as a tenant from it. Budget two weeks for the first developer to learn content types, placement files and Liquid before the first real site ships. If you have one site and no C# in the building, do not start here; Umbraco if you are staying on .NET, Ghost or WordPress if you are not. Orchard Core rewards exactly one kind of user, and it rewards that user handsomely.