JSS deployment best practices and security

Current version: 20.x

The deployment procedure for JSS applications varies based on the development workflow.

In production, most apps use Sitecore-first workflow.

For a Sitecore-first workflow, normal Sitecore DevOps best practices apply, such as:

  • Have a repeatable, fully automated deployment process.

  • Use an item serialization tool like Unicorn or TDS to source control and deploy developer-owned Sitecore items (templates, renderings, and so on), including those of JSS site(s).

Specifically for JSS, we also recommend:

  • Consider storing Sitecore back-end code and JSS site code in the same source control repository to avoid issues synchronizing changes between the front and back end, and enable developers to easily commit, test, and revert changes. This also makes it easy to build and deploy JSS site artifacts to Sitecore during CI builds.

  • Automate the deployment of Sitecore updates and JSS site updates in headless mode into a single build process, to avoid defects caused by deploying different versions of the front end and back end.

  • To enable storing JSS connection and deployment information in deployment variables, you can use several options with the jss setup command.

Tip

When running jss CLI commands in an environment where you cannot install global npm packages, you can use npm run jss [command] instead, which aliases the CLI command through npm.

Use -- before any arguments for the commands you run with npm. For example, npm run jss deploy app -- --skipBuild

The Import Service

The Import Service is used to deploy code-first Sitecore item artifacts to Sitecore, as well as for Sitecore-first developer scaffolding. This service is automatically installed when installing Sitecore Headless Services.

  • The deployment service uses shared secrets for authentication. These must be unique per environment, randomly generated (no passphrases), and at least 32 characters. The shared secret uses HMAC with the package being deployed as a factor, so there is signature validation that the package is not tampered with and the shared secret is never sent over the wire.

  • We strongly recommend running all Sitecore HTTP services, including import service, over TLS-secured channels even with signature validation.

  • The Import Service is automatically disabled when the Sitecore server role is not Standalone for local development or ContentManagement for production. Importing JSS apps is not allowed on public-facing servers automatically.

  • If you want to deploy IP whitelisting to the import service, you can do this at a network level.

File deployment

The JSS deployment service intentionally does not accept files to be deployed, to keep its attack surface as minimal as possible. You must deploy files of JSS build artifacts using techniques suitable for any other Sitecore deployment, such as update packages, direct file copy, or Microsoft Web Deploy. There are no JSS-specific considerations around file deployment.

Do you have some feedback for us?

If you have suggestions for improving this article,