In our case, both test and prod environments are Azure app services. So currently when we deploy to test:

  1. I replace the layoutServiceHost and deployUrl in scjssconfig.json to be the address of QA environment on my local
  2. Run jss deploy files on my local
  3. Copy resulting dist folder to the test environment (cm and cd)

This works, but having to edit a config file manually bothers me as it does not seem like a good and viable solution from a long-term view point & considering having to deploy to prod later too. What are the recommended/other ways to do it? Thank you

2 Answers 2


We have two scjssconfig.json files in root of our solution. One with the same name that is used by developers and second one with .dist suffix in name.

During build we remove the file without suffix and remove.dist suffix from the other.

scjssconfig.json.dist looks like this:

  "sitecore": {
    "instancePath": "d:\\home\\site\\wwwroot",
    "apiKey": "{apiKeyGUIDOmmittedForSSE}",
    "deploySecret": "DeploySecretOmmittedForSSE",
    "deployUrl": "",
    "layoutServiceHost": ""

as you can see layoutServiceHost is blank. We have no problem with this setup in any of environments QA/INT/PROD/PREPROD.

You can do something similar for both layoutServiceHost and deployUrl in your case. So you just do this "replacement" before build, build solution on Build Server and deploy automatically to your environment without manual steps...


Another solution would be to add support for environment variables in your JSS bundle. It was added already for Next.js: https://github.com/Sitecore/jss/pull/527/files but it works also for React with one difference in generate-config.js:

instead of const computedConfig: { [key: string]: string } = {};

use just const computedConfig = {};

rest of the changes in your code shall be the same as in pull request for Next.js

For SSR Proxy variables are already supported: https://github.com/Sitecore/jss/blob/master/samples/node-headless-ssr-proxy/config.js

With this approach you don't need to create artifacts with different bundles per environment, but control the variable in Release Pipeline, for example in Azure DevOps App Service Deploy task with Application Settings:

-SITECORE_API_KEY $(sitecoreApiKey) -SITECORE_API_HOST $(sitecoreUri)

or in in App Service Settings task in Application Settings:

      "name": "SITECORE_API_HOST",
      "value": "$(sitecoreUri)",
      "slotSetting": false
      "name": "SITECORE_API_KEY",
      "value": "$(sitecoreApiKey)",
      "slotSetting": false

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.