Service Registration

Learn how to configure Umbraco to run only the services required on each specific server in your setup.

Umbraco can be configured to run with different combinations of the backoffice, website, and Content Delivery API. This allows you to tailor each server in your infrastructure to its specific role, reducing attack surface and unnecessary processing.

Supported Configurations

By default, Umbraco registers all services: the backoffice, website rendering, and Content Delivery API. However, you can choose to run only the services you need.

The following configurations are supported:

Configuration
AddCore()
AddBackOffice()
AddWebsite()
AddDeliveryApi()

Full (default)

Website + Delivery API

Website Only

Delivery API

Only

The key distinction is between AddBackOffice() and AddCore():

  • AddBackOffice() registers everything needed for the Umbraco backoffice, including the Management API, backoffice identity, and all supporting services.

  • AddCore() registers only the foundational Umbraco services — configuration, core services, web components, caching, and background jobs — without any backoffice-specific services.

AddBackOffice() calls AddCore() internally, so there is no need to call both.

circle-info

AddCore() is idempotent. If both AddBackOffice() and AddCore() are called, the core services are only registered once.

Configuration use cases

  • Full (default): Traditional Umbraco with all features enabled.

  • Website + Delivery API: Front-end servers serving both rendered pages and headless content.

  • Website Only: Front-end servers serving only rendered pages.

  • Delivery API Only: Pure headless API servers.

Full Umbraco (default)

The following is the standard configuration that includes the backoffice, website rendering, and Content Delivery API.

When you install a new Umbraco project, this is what you will see in the Program.cs file:

Website + Delivery API (no backoffice)

The following configuration is useful for front-end servers in a load-balanced setup where a single backoffice instance is running.

The server can render pages and serve headless content, but the backoffice is not available.

Website only

The following configuration is used for front-end servers that only serve rendered pages. Neither the backoffice nor the Content Delivery API is available.

Delivery API only

The following configuration is used for pure headless API servers. Only the Content Delivery API is available — no website rendering and no backoffice.

Key differences between configurations

Middleware

  • UseBackOffice() — Registers middleware for the backoffice, including authentication and authorization. Only needed when using AddBackOffice().

  • UseWebsite() — Registers middleware for website rendering. Needed when using AddWebsite().

Endpoints

  • UseBackOfficeEndpoints() — Maps the Management API controllers and backoffice routes. Only needed when using AddBackOffice().

  • UseWebsiteEndpoints() — Maps website rendering endpoints. Needed when using AddWebsite().

  • UseDeliveryApiEndpoints() — Maps the Content Delivery API controllers. Use this when running the Delivery API without the backoffice.

circle-info

UseDeliveryApiEndpoints() is only needed when running the Delivery API without the backoffice. When the full backoffice is enabled, UseBackOfficeEndpoints() handles mapping all API controllers, including the Delivery API.

Considerations for Composers

When building packages or custom code using Composers, be aware that some services are only available when the backoffice is enabled. If your Composer depends on backoffice-specific services, it will not work on servers configured with AddCore().

You can check whether the backoffice is enabled by looking for the IBackOfficeEnabledMarker in the service collection:

Last updated

Was this helpful?