---
schema_version: "1"
id: 4aca7af87c504c5bdf14e3cf860d38e8e6e09147e58fabb12dafe34e1b6914ab
title: Managed Runtime (MRT) Data Store
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/commerce-cloud/sfnext/guides/sfnext-mrt-data-store.md
canonical_url: https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/sfnext-mrt-data-store.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 61d00885a13fd9ff43c93675ba67ca61be20e7807cae16b6c0e5a5bd786e4485
products:
  - Composable Storefront
  - Salesforce APIs
---
# Managed Runtime (MRT) Data Store

The MRT data store stores B2C Commerce settings, such as site preferences and Page Designer changes, and makes those settings available to Storefront Next. Your Storefront Next app accesses settings from the data store, which makes settings retrieval faster and more performant because there is no need for B2C Commerce API (SCAPI) calls to get those settings. Also, page descriptions for changed Page Designer pages are stored in the data store where the storefront gets them, eliminating the need to build page layouts for each shopper request.

In this section:

- [Access Site Preferences from the MRT Data Store](#access-site-preferences-from-the-mrt-data-store)
- [Page Designer Change Deployment to Storefront Next](#page-designer-change-deployment-to-storefront-next)

## Access Site Preferences from the MRT Data Store

Use the Managed Runtime (MRT) data store to get site preferences that administrators set in Business Manager. Access site preferences in different contexts within your Storefront Next app.

**important:** Sensitive values, such as passwords, are masked when stored in the MRT Data Store. When you retrieve sensitive values in the Storefront Next app, the returned values are masked.

### Configuration

The data store middleware is bundled and exported as `dataStoreMiddlewareLazy`. It is an array of React Router middleware functions that load site preferences, global preferences, and other preferences into the router context on every request. It defers retrieving the preferences until a loader actually requests the value. Register it in `src/root.tsx`. Make sure that `siteContextMiddleware` runs first so that the site-preferences middleware can resolve the current site ID. The `siteContextMiddleware` runs on every request to resolve the current site, locale, and currency from the request, checking path, query string, cookie, and header in priority order. It stores the resolved values in the router context so they're accessible to loaders, actions, and components via `useSite()`, then sets the appropriate cookies on the response if the values changed. It also skips overwriting any site, locale, and currency cookies that an action or loader already set earlier in the response.

**note:** The Storefront Next retail template configures the data store middleware for you.

```typescript
// src/root.tsx

import { dataStoreMiddlewareLazy } from "@salesforce/storefront-next-runtime/data-store";

export const middleware: MiddlewareFunction[] = [
  siteContextMiddleware,
  ...dataStoreMiddlewareLazy,
  // ... rest of middleware
];
```

MRT sets these required environment variables in production:

- `AWS_REGION`
- `MOBIFY_PROPERTY_ID`
- `DEPLOY_TARGET`

Optionally, set `SFNEXT_DATA_STORE_UNAVAILABLE_MODE = throw` to fail the request instead of returning an empty object when the data store is unreachable. The default value is `fallback`, which returns an empty object.

### Usage in root.tsx (Server Middleware)

```typescript
// src/root.tsx
import {
  getCustomGlobalPreferencesLazy,
  getSitePreferencesLazy,
} from "@salesforce/storefront-next-runtime/data-store";

const maintenanceMiddleware: MiddlewareFunction = async ({ context }, next) => {
  const sitePrefs = (await getSitePreferencesLazy(context)) ?? {};
  const globalPrefs = (await getCustomGlobalPreferencesLazy(context)) ?? {};

  if (sitePrefs.maintenanceMode || globalPrefs.maintenanceMode) {
    return new Response("Maintenance", { status: 503 });
  }

  return next();
};
```

### Usage in Route Loaders

Use the async getters in any server loader or action. Both getters return a `Promise` that resolves to `Record<string, unknown> | null`. Use `?? {}` or a similar fallback to handle the `null` case when the entry is missing or the data store is unavailable.

```typescript
// src/routes/home.tsx
import {
  getCustomGlobalPreferencesLazy,
  getSitePreferencesLazy,
} from "@salesforce/storefront-next-runtime/data-store";

export async function loader({ context }: Route.LoaderArgs) {
  const sitePrefs = (await getSitePreferencesLazy(context)) ?? {};
  const globalPrefs = (await getCustomGlobalPreferencesLazy(context)) ?? {};

  return {
    showBanner: Boolean(sitePrefs.showBanner),
    enableChat: Boolean(globalPrefs.enableChat),
  };
}
```

### Usage in React Components

To access site preferences in React components, read them in the route loader and pass them to components via `useLoaderData`. There is no client-side hook for site preferences.

```typescript
// src/routes/home.tsx
export default function Home({ loaderData }: Route.ComponentProps) {
  const { showBanner, enableChat } = loaderData;

  return (
    <div>
      {showBanner && <HeroBanner />}
      {enableChat && <ChatWidget />}
    </div>
  );
}
```

### Local Development

Use `MRT_DATA_STORE_DEFAULTS` to seed values without a real data store. Prefix site preference keys with the site ID.

```bash
MRT_DATA_STORE_DEFAULTS='{ "custom-global-preferences": {"enableChat": true},
  "RefArch-custom-site-preferences": {"productsPerPage": 24} }' pnpm dev
```

Data Store Keys:

- Global: `custom-global-preferences`
- Site: `{siteId}-custom-site-preferences`

### Site Preferences Sync Frequency

A system job syncs site preferences to the data store based on the B2C Target Info and Site IDs configured for the Managed Runtime environment. Site preferences can take up to 5 minutes to take effect.

## Page Designer Change Deployment to Storefront Next

When a merchant makes a change to Page Designer pages and components in staging, a system job deploys the page and component metadata, and content to Managed Runtime (MRT). B2C Commerce prebuilds each Page Designer page and sends it to the MRT data store. The storefront reads the page metadata from the data store instead of assembling the page on every shopper request. This approach improves storefront performance by eliminating the need to build page layouts dynamically for each shopper.

You don't author manifests manually. The system automatically builds them from your Page Designer pages without any changes required from you in Business Manager.

**note:** The Page Designer update mechanism described here applies only to Storefront Next. It doesn't apply to other storefront types, including PWA Kit, SFRA, or Site Genesis.

## How Changes in Page Designer Reach Storefront Next

Two preconfigured system jobs deliver manifests to your storefront.

- `sfcc-push-page-manifests`: The system runs this job automatically on production after replication every 5 minutes. This job picks up the manifests that have been replicated from staging and pushes them to the MRT data store.
- `sfcc-generate-and-push-page-manifests`: Run this job manually on production or development instances to push changes to the data store immediately. From Business Manager, go to **Administration > Operations > Jobs**, locate the job, and run it. This job generates manifests from the current instance and pushes them to the data store.

After either job runs, check the results in Business Manager at **Administration > Operations > Job History**. A successful job shows a status of **OK** or **Finished**. If the job fails, review the log details to identify the issue.

### Typical Page Update Flow

Follow this workflow to publish Page Designer changes to your storefront:

1. Author content: A merchant authors page content in Page Designer on the staging instance.
2. Replicate to production: An administrator replicates the changes from staging to production.
3. Wait for automatic sync: The system automatically runs the `sfcc-push-page-manifests` job on production after replication completes.
4. Verify on storefront: Shoppers see the updated content on the storefront. Verify the changes by viewing the affected pages.

### Update Pages Changed Directly on Production

If you make changes directly on production without replicating from staging, the automatic job doesn't pick them up. To push these changes immediately:

1. From Business Manager, go to **Administration > Operations > Jobs**.
2. Locate the `sfcc-generate-and-push-page-manifests` job.
3. Click **Run** to execute the job.
4. Verify that the job completed successfully in **Administration > Operations > Job History**.
5. Check the affected pages on your storefront to confirm the changes appear.

## See Also

- [Page Designer Content Management for Merchants](https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/sfnext-page-designer-customize-sf.md)