Skip to main content

Sitecore Headless Development FAQ


Answers to some of the most frequently asked questions about Sitecore Headless Development.

This topic answers some of the most frequently asked questions about Sitecore Headless Development with ASP.NET.

What are the benefits of Sitecore Headless Development?

Sitecore Headless Development introduces efficiencies in developing, maintaining, scaling, and upgrading Sitecore solutions.

Using the same Sitecore Headless Services that power JSS gives faster development iterations by building straight from Visual Studio to a rendering host. This allows you to test changes without waiting for the Sitecore installation to restart.

Using ASP.NET Core Rendering SDK when doing native integration with existing ASP.NET Core applications poses fewer problems.

Will infrastructure costs be cheaper in production with Sitecore Headless Development?

Infrastructure costs are allocated differently and might be cheaper or more expensive depending on the data flow of your Sitecore solution.

With Sitecore Headless Development, you run the following instances:

  • A Content Delivery (CD) instance carrying less load because it no longer handles the presentation layer. The CD instance still handles tracking, Sitecore Layout Service requests, GraphQL queries, personalization, and so on.

  • A lightweight rendering host that handles the presentation layer.

If your presentation layer is a heavy load on your infrastructure, then using a rendering host and perhaps a solid caching strategy can help reduce horizontal scaling costs. A rendering host can scale out at a lower cost than a Content Delivery instance. In some solutions, Content Delivery still needs to scale out to handle requests from an increased number of rendering hosts.

Is Sitecore Headless Development an add-on like Sitecore JavaScript Services?

If you have access to Sitecore JavaScript Services (JSS), you also have access to Sitecore Headless Development. Both development approaches leverage the same interfaces.

Can I still use MVC or Sitecore Experience Accelerator with Sitecore?

All existing development options are available in Sitecore 10.0 and later, and you can upgrade without changing your development model. The new ASP.NET Rendering SDK merely provides an additional option for building Sitecore solutions.

Can I use the ASP.NET Rendering SDK without using Sitecore Containers?

Sitecore Containers eases the setup of your development environment, but it is not a requirement for Sitecore Headless Development. You can build Sitecore solutions with ASP.NET Rendering SDK in any type of supported infrastructure or hosting model.

What features are not supported in Sitecore Headless Development?

For Sitecore version 10.0, the following features are not compatible with Sitecore Headless Development:

  • Horizon

  • Edit frames

  • Sitecore Forms

  • Invocation of xConnect events, goals, and outcomes from C#

Are rendering hosts available on a Managed Cloud infrastructure?

Managed Cloud Standard and Managed Cloud Premium do not currently offer headless topologies for rendering hosts.

With Sitecore Headless Development, do any development artifacts still need to be deployed to Content Delivery?

For more complex components, you might need to deploy content resolvers or write GraphQL queries to support your rendering host components.

You also must deploy any site definition configuration patches to your Content Delivery instances.

Can I use Sitecore Experience Accelerator with an ASP.NET Rendering SDK application?

At this time, the ASP.NET Rendering SDK does not support Sitecore Experience Accelerator (SXA) renderings. Rendering hosts can be used with the existing JSS tenant of SXA to take advantage of SXA features such as multisite, designs, partials, and so on.

Can I build using Blazor, RazorPages, and SignalR?

Sitecore only tests and supports MVC sites in the rendering host.

Can I run separate JSS and ASP.NET Rendering SDK multisite instances from the same Sitecore instance?

JSS and ASP.NET Rendering SDK multisite instances uses the same type of site definition. For Content Management, whether the site is running JSS or ASP.NET Rendering SDK is not relevant.