Managed Runtime Overview

Managed Runtime provides the infrastructure to deploy, host, and monitor your PWA Kit storefront.

This guide covers the main parts of Managed Runtime and how to access it.

Before you can use Managed Runtime, you must request access. Contact your Commerce Cloud administrator and ask them to add either one of the following roles to your account using Account Manager: Managed Runtime User or Managed Runtime Admin.

An environment is the term used to describe all of the cloud infrastructure and configuration values for a particular storefront hosted by Managed Runtime. Environments are used to separate your production storefront from other storefronts that are deployed for other purposes, such as development or testing.

In the Managed Runtime API, environments are called “targets,” but both terms refer to the same thing.

Because environments run on highly efficient microservices that automatically scale up and down, you can create as many environments as you need at no additional cost. For example, you could create a short-lived environment dedicated to a single agile development sprint or for a single user story within that sprint. When you no longer need an environment, we encourage you to delete them.

The storefront code that runs on an environment is called a bundle. Use the developer tools included in PWA Kit to generate a bundle and push it to Managed Runtime.

A bundle is a snapshot of your code at a specific point in time. It’s immutable: After a bundle has been created, it can’t be changed. Having this complete and accurate history of bundles makes troubleshooting deployments easier.

After pushing the bundle, you can use the Runtime Admin or Managed Runtime API to designate that bundle as “deployed.” Each project can have multiple bundles, but each environment can have only one bundle that's designated as deployed. You can change which bundle is designated as deployed at any time. For more information, see Push and Deploy Bundles.

To help you manage multiple environments, each environment also belongs to a project and each project belongs to an organization. An organization can contain multiple projects for multiple storefronts and each project can contain multiple environments. A Managed Runtime user can belong to multiple organizations to separate different work streams.

Each organization can have a maximum of 100 total environments and a maximum of 10 production environments. If you need to raise these limits, contact your Salesforce Support representative.

Organizations are created in Account Manager and replicated in Managed Runtime. Membership in an organization is determined by membership settings in Account Manager. A user can belong to an organization as either a member or an admin. Members can only interact with the projects in Managed Runtime that they’ve been assigned a project role to. Admins can interact with all the projects within an organization.

A user can have the following abilities for a Managed Runtime project:

  • Browse: View the project in Runtime Admin.
  • Manage Redirects: Manage redirects for the project.
  • Deploy: Deploy new bundles or revert the deployment to an older bundle.
  • Manage Team: View, add, invite, remove, and edit the roles of team members for the project.

Each user is assigned a project role that determines which abilities they have. (A user can only have one role.) Project roles can be assigned to any user within an organization.

The following table shows which abilities are associated with each role:

RoleBrowseManage RedirectsDeployManage Team
AdminYesYesYesYes
DeveloperYesYesYesNo
MarketerYesYesNoNo
Read OnlyYesNoNoNo

Within each Managed Runtime environment, the React app in the published bundle runs inside a Node.js environment. To respond to page requests and render the results, we use the Express web framework with the help of PWA Kit’s rendering and routing systems. We call this combination of React, Node, and Express the App Server. (Although, technically speaking, the App Server runs on “serverless” technology.) The App Server is optimized to run on cloud infrastructure that offers low computing costs, high availability, fast rendering, and massive scaling capacity.

Because PWA Kit’s rendering and routing system handles the differences between local development environments and Managed Runtime environments, your code runs in a predictable way when you deploy it. This predictability unlocks your development team’s productivity by encouraging them to deploy bundles more frequently.

Currently, the App Server supports Transport Layer Security (TLS) versions 1.2 and greater.

All storefront bundles must use Node 14.x.

Environment Variables

Code running on the App Server has access to the following environment variables:

  • DEPLOY_TARGET: ID of the environment.
  • EXTERNAL_DOMAIN_NAME: The domain name set on the environment.
  • MOBIFY_PROPERTY_ID: ID of the project that the environment belongs to.

Supporting the app server are several edge services, including:

  • A web application firewall (WAF) to protect your environments from attackers
  • A proxy server to speed up API requests
  • A content delivery network (CDN) to cache requests and speed up page loading
  • Edge functions that process requests and handle redirects

The proxy server and CDN are covered in detail in our guide to Proxying Requests. The edge function called the request processor is covered in our guide to Maximizing Your Cache Hit Ratio.

Managed Runtime’s edge services are strategically distributed throughout our public cloud infrastructure. Each service is located as close to the user as possible for faster performance.

To manage the settings for your organizations, projects, environments, and bundles, we offer two different tools:

  1. The Managed Runtime Admin, a web-based UI.
  2. The Managed Runtime API, a REST API that offers the same functionality as the web-based tool and some additional capabilities.

Use the Runtime Admin tool for routine tasks, such as deploying a new code bundle to an environment. Use the API whenever you need programmatic control, such as automatically creating an environment as part of a continuous integration script.

The admin tools give you a self-serve way to configure many settings, including:

  • Allowed IP addresses
  • Currently deployed bundle
  • Deployment region
  • Proxies
  • Redirects
  • User permissions

Some settings require you to open a support request, including:

  • Static IP addresses (for VPN)

Access to the admin tools is controlled with Account Manager roles and an API key. For continuous integration (CI) and continuous delivery (CD) processes, dedicated bot users with their own API keys are typically provisioned by your organization.

Fun fact: Like your storefront, the Runtime Admin tool is a headless React app that is deployed to Managed Runtime.

While building your storefront, keep the following constraints of Managed Runtime environments in mind:

  • The path / only accepts HTTP GET requests.
  • Request and response size can’t exceed 6 MB.
  • The Set-Cookie header is not supported.
  • The App Server request execution time limit is 20 seconds.
  • Unhandled promise rejections break app rendering.
  • You can bypass the CDN cache using the HTTP request header: x-mobify-cachebreaker: 1

Now that you have an overview of the main parts of Managed Runtime, it’s time to get hands-on! A good place to start is the Push and Deploy Bundles guide.

Before you can use Managed Runtime, you must request access. Contact your Commerce Cloud administrator and ask them to add either one of the following roles to your account using Account Manager: Managed Runtime User or Managed Runtime Admin.