Deploy without the administration

Deployment without the Xperience by Kentico administration is currently not supported when deploying to the SaaS environment. The scenario described on this page applies only to self-managed deployments.

Xperience and all related dependencies are installed via NuGet packages. The installed packages dictate the features available to each project. However, not all packages are required for Xperience sites to run in production environments.

The Xperience administration interface (installed via the Kentico.Xperience.Admin NuGet package) and all related customizations can be removed when publishing to production. In these types of environments, you can have:

One Xperience instance with the administration interface. Access to this instance is restricted only to authorized users (i.e., placed behind a firewall or on a private network). This is where content editors and other users work with the system.
Another Xperience instance without the administration interface. This is the instance with which regular live site visitors interact.
Both instances connect to the same database.

Advantages

Increased security – removing the administration from public-facing sites reduces the attack surface available to malicious actors.
Improved performance – removing the administration reduces application overhead, which is beneficial for sites with significant traffic. For example, the administration registers a separate middleware pipeline for user authentication, which is unnecessary for the live site.

Disadvantages

Deployment complexity – preparing a separate instance without the administration and its dependencies increases the complexity of your environment and adds extra steps to your deployment process.

In the most basic scenario, you can set up and deploy Xperience without the administration manually:

Create a separate copy of your Xperience application.
Uninstall the Kentico.Xperience.Admin NuGet package and remove any custom code intended only for the administration.
Deploy both applications – the original to an environment with restricted access and the new copy without the administration to production.

However, in most cases, we recommend that you integrate the separation into an automated publishing script or pipeline.

Sample automated separation process

This section outlines an approach that modifies the application’s build process to remove the Kentico.Xperience.Admin NuGet package and all related dependencies, including custom code intended only for the administration. The demonstrated approach is suitable for use in publishing scripts or automation pipelines.

Edit your Xperience application’s .csproj file and add a new AdminAttached MSBuild property:

Xperience application's .csproj file



 <PropertyGroup>
     <TargetFramework> <!-- ... --> </TargetFramework>
     <RootNamespace> <!-- ... --> </RootNamespace>
     <!-- Defines an MSBuild property that defaults to true 
          if not explicitly passed to MSBuild as a parameter -->
     <AdminAttached Condition="'$(AdminAttached)' == ''">true</AdminAttached>  
 </PropertyGroup>

Add the following condition to the Kentico.Xperience.AspNetCore.Admin package reference using the Condition attribute:

Xperience application's .csproj file



 <ItemGroup>
     ...
     <!-- If the specified condition evaluates to true (true by default), the project maintains this package reference -->
     <PackageReference Include="kentico.xperience.admin" Version="..." Condition="'$(AdminAttached)' == 'true'" />
 </ItemGroup>

Follow a similar process to remove any custom code when customizing the administration interface or some of its components. Assuming your code follows best practices for admin UI customization outlined in Admin UI customization model overview, your administration-related code is located in isolated assemblies/NuGet packages, making the process straightforward. Repeatedly add the Condition attribute to all relevant references:
Xperience application's .csproj file
```
 
 <ItemGroup>
     ...
     <ProjectReference Include="..\Acme.Web.AdminCustomCode.csproj" Condition="'$(AdminAttached)' == 'true'" />
 </ItemGroup>  

 
 <ItemGroup>
     ...
     <PackageReference Include="Emca.Web.AdminCustomCode" Version="..." Condition="'$(AdminAttached)' == 'true'" />
 </ItemGroup>

 
```
If you also need to make specific code outside dedicated assemblies run only when the administration is attached, declare a conditional compilation constant and use it as required:
Xperience application's .csproj file
<PropertyGroup Condition="'$(AdminAttached)' == 'true'"> <DefineConstants>$(DefineConstants);ADMIN_ATTACHED</DefineConstants> </PropertyGroup>
ADMIN_ATTACHED usage
#if ADMIN_ATTACHED // Surrounded code only compiles when administration dependencies are present #endif
You can also invert this condition to run code only when the administration is detached.
When you need to publish the project without admin UI packages and dependencies, pass AdminAttached=false as a parameter to MSBuild:
```
 dotnet publish -c Release -p:AdminAttached=false --output <OUTPUT_DIRECTORY>

 
```

The output directory now contains the published application minus the dependencies marked by the AdminAttached condition.