####
In Sitecore, we have a separation between rendering and editing hosts. Where:
- **The rendering host** - is the front-end application that is used for displaying the website to your audience. You host the application on platforms such as Vercel, Netlify, or even on your own Node.js server. This application is set up and scaled to serve live traffic.
- **The editing host** - serves the purpose of editing experiences inside the XM Cloud instance and is not set up or scaled for serving live traffic.
Rendering host runs on third-party services - it is more or less clear because we follow the instructions and documentation of the service. But in the case of the editing host - it is a kind of black box. The editing host app runs inside XM Cloud and a build and execution process is not so obvious.
Sitecore provides the [XM Cloud Starter Kit (Next JS)](https://github.com/sitecorelabs/xmcloud-foundation-head) and pretty well [describes](https://doc.sitecore.com/xmc/en/developers/xm-cloud/walkthrough--creating-an-xm-cloud-project-using-the-sitecore-cli.html)the process of creating our own project based on this starter kit. But what if we want to deploy and run our existing rendering host application as an editing host? It is surely possible but has a few peculiarities:
- Version of Sitecore JavaScript Rendering SDKs (JSS) should be 19.0.0 or newer
- It should be a JSS, node.js-based application
- Your application should not depend on any custom environment variables because the environment variables for Editing Host cannot be set in the [environment variables UI](https://doc.sitecore.com/xmc/en/developers/xm-cloud/manage-environment-variables-in-the-xm-cloud-deploy-app.html)
- Your application should support the Experience Editor and built in accordance with all best practices of it.
If our app matches all points above, you can run your app as an editing host within XM Cloud.
First of all, we need to make sure that we have *xmcloud.build.json* in the root of our solution. This [article](https://doc.sitecore.com/xmc/en/developers/xm-cloud/the-xm-cloud-build-configuration.html)describes which parameters we have in the configuration. You should have it if you already deploy your backend part into the XM Cloud. If not, create it manually with the following content:
| {
"deployItems": {
"modules": [
"Foundation.\*",
"Feature.\*",
"project.\*"
]
},
"buildTargets": [
"./DemoCloud.sln"
],
"renderingHosts": {
"global": {
"path": "./src/Project/Demo/nextjs",
"nodeVersion": "14.15.3",
"jssDeploymentSecret":"dd5d764c4776459e92e1233b8cde0ab5",
"enabled": true,
"type": "sxa"
}
}
} |
| --- |
In this article we are interested only in **renderingHosts** properties, where the most important of them are:
- global - is a jss app name,
- Path - The relative path from the xmcloud.build.json file to the app source code. Usually, it is the relative path from the root folder,
- nodeVersion - Specific Node.js version for rendering host
- Type - type of rendering host. Allowed values: "jss" or "sxa"
Once you are done with the [deployment](https://doc.sitecore.com/xmc/en/developers/xm-cloud/walkthrough--creating-an-xm-cloud-project-using-the-sitecore-cli.html), you should see the following item created under the /sitecore/system/Settings/Services/Rendering Hosts/ :
If you use the latest versions if JSS and SXA, you should have the **Predefined application rendering host** field for the SXA site definition where you have to select a proper rendering host:
If you don’t have the field above, but still use SXA, you should copy values from */sitecore/system/Settings/Services/Rendering Hosts/global* to your Site settings:
And finally, if you don’t use SXA at all, you should make sure your app config looks like below:
| <?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"
xmlns:set="http://www.sitecore.net/xmlconfig/set/">
<sitecore>
<sites>
<!--
JSS Site Registration
This configures the site with Sitecore - i.e. host headers, item paths.
If your JSS app lives within an existing Sitecore site, this may not be necessary.
-->
<site name="global"
inherits="website"
hostName="$(env:host)"
rootPath="/sitecore/content/Global"
patch:before="site[@name='website']" />
</sites>
<javaScriptServices>
<apps>
<!--
JSS App Registration
The JSS app needs to be registered in order to support layout service and import services.
There are many available attributes, and they inherit the defaults if not explicitly specified here.
Defaults are defined in `/App_Config/Sitecore/JavaScriptServices/Sitecore.JavaScriptServices.Apps.config`
NOTE: graphQLEndpoint enables \_Integrated GraphQL\_. If not using integrated GraphQL, it can be removed.
NOTE: This app configuration assumes a Sitecore-first approach and thus disables the JSS Workflow for
initial app import, and does not protect imported items.
-->
<app name="global"
sitecorePath="/sitecore/content/Global"
graphQLEndpoint="/sitecore/api/graph/edge"
serverSideRenderingEngine="http"
serverSideRenderingEngineEndpointUrl=
"$(env:RENDERING\_HOST\_INTERNAL\_URI\_global)/api/editing/render"
serverSideRenderingEngineApplicationUrl=
"http://$(env:SITECORE\_EDITING\_HOST\_PUBLIC\_HOST\_global)"
useLanguageSpecificLayout="true"
defaultWorkflow=""
protectDeveloperItems="false"
deploymentSecret="$(env:JSS\_DEPLOYMENT\_SECRET\_global)"
debugSecurity="false"
inherits="defaults" />
</apps>
</javaScriptServices>
</sitecore>
</configuration> |
| --- |
Or you can replace values for *serverSideRenderingEngineEndpointUrl* and *serverSideRenderingEngineApplicationUrl* with values from the */sitecore/system/Settings/Services/Rendering Hosts/global* item.
One more important thing related to the JSS\_EDITING\_SECRET. In NON XM Cloud project, we usually secure the Sitecore editor endpoint using a Sitecore configuration patch with the following setting:
| <setting name="JavaScriptServices.ViewEngine.Http.JssEditingSecret" value="<YOUR\_SECRET\_TOKEN>" /> |
| --- |
In XM Cloud this setting is patched from the *Sitecore.JavaScriptServices.ViewEngine.Http.config*:
| <setting name="JavaScriptServices.ViewEngine.Http.JssEditingSecret" value="some value" patch:source="Sitecore.JavaScriptServices.ViewEngine.Http.config"/> |
| --- |
If you override this setting, your editing host app will not work. So, you have to remove your patch if you have one.
###### More from author
[##### Deploy custom headless Sitecore solution in Sitecore XM Cloud
November 10, 2022](https://www.brimit.com/blog/deploy-custom-headless-sitecore-solution-in-sitecore-xm-cloud)[##### Running node.js based rendering host in Sitecore Managed Cloud
August 3, 2022](https://www.brimit.com/blog/running-node-js-based-rendering-host-in-sitecore-managed-cloud)[##### Running node.js based rendering host in AKS
June 17, 2022](https://www.brimit.com/blog/running-node-js-based-rendering-host-in-aks)
###### Author
[!\[artsiom-photo\](https://www.brimit.com/-/jssmedia/feature/blogs/authors/artsiom-200.jpg?h=202&iar=0&w=200&hash=41797D2540DF6EB6FDF558360F6F62B8)
Artsem Prashkovich
Sitecore MVP/ Solution Architect](https://www.brimit.com/blog/author?authors=Artsem%20Prashkovich)
###### More by category
[#Events](https://www.brimit.com/blog?categories=#Events)[#How-to](https://www.brimit.com/blog?categories=#How-to)[#News](https://www.brimit.com/blog?categories=#News)[#Guides](https://www.brimit.com/blog?categories=#Guides)
###### More by platform
[DXP](https://www.brimit.com/blog?platforms=DXP)[Sales and marketing automation](https://www.brimit.com/blog?platforms=Sales%20and%20marketing%20automation)[Application innovation](https://www.brimit.com/blog?platforms=Application%20innovation)
#### More on Sitecore
[!\[How Vercel Will Help You Save Effort When Deploying Sophisticated Sitecore Projects\](https://www.brimit.com/-/jssmedia/project/brimit/blog/2024/vercel_cover-image.png)
#Guides#How-toDXPE-commerce
##### How Vercel Will Help You Save Effort When Deploying Sophisticated Sitecore Projects
Optimize and accelerate the development and deployment of complex multisite Sitecore projects.
Alexei Vershalovich on July 17, 2024](https://www.brimit.com/blog/how-vercel-will-help-you-save-effort-when-deploying-sophisticated-sitecore-projects)
[!\[Training Up Tomorrow's Sitecore MVPs: a Mentoring Success Story\](https://www.brimit.com/-/jssmedia/project/brimit/blog/2023/sitecore-mentoring---cover-image.png)
#How-toDXP
##### Training Up Tomorrow's Sitecore MVPs: a Mentoring Success Story
How to participate in the Sitecore Mentor program and help younger colleagues jump-start a career in Sitecore development.
Sergey Baranov on October 2, 2023](https://www.brimit.com/blog/training-up-tomorrows-sitecore-mvps)
[!\[Going Headless. Part 2: When a Headless CMS Is Your Best Bet (if you have Sitecore)\](https://www.brimit.com/-/jssmedia/project/brimit/blog/2022/headless/adobestock_456986731.jpg)
#How-toDXPE-commerce
##### Going Headless. Part 2: When a Headless CMS Is Your Best Bet (if you have Sitecore)
Discover how a headless CMS can benefit organizations that use Sitecore.
Daniil Raschupkin, Palina Trokhautsava on September 15, 2022](https://www.brimit.com/blog/going-headless-part-2-when-a-headless-cms-is-your-best-bet-if-you-have-sitecore)
