XM Cloud & Vercel - Deployment Protection and Setting Relative Asset Urls

Summary

We decided to leverage the out of the box Deployment Protection (opens in a new tab) that Vercel offers on our project. We wanted to secure our lower DEV and QA environments on our Next.js headless application. This would allow us to develop new features and test without exposing anything to the public internet.

We ran into an issue where our JS and CSS references were broken under Vercel's Deployment Protection. The assets would load from the dynamic Vercel url at build time and error out.

The Solution

The solution was to make the url paths relative in the headless application, but still keep the public url path for Experience Editor and Pages and their internal rendering host.

The fix was accomplished in two parts.

1. Add a new environment variable to our XM Cloud internal rendering host called XMC_DEFAULT_RH.

To add a new variable for you rendering host, navigate to the XM Cloud Deploy app and select the appropriate project and environment. Next, select Variables and then Create variable.

Next, add the name of our new variable XMC_DEFAULT_RH. Set the value to true, target to Rendering Host and set the proper rendering host name. In our case we are using the out of the box Default.

2. Modify the next.config.js in our headless application. Specifically, we wanted to add some logic to the assetPrefix configuration to allow the full public url for Sitecore's internal rendering host, but still allow the relative url for Vercel.

We added the following:

const nextConfig = {
  assetPrefix: process.env.XMC_DEFAULT_RH === "true" ? publicUrl : undefined,

We need to make sure to redeploy to both Sitecore and Vercel to see our changes reflected.

Now, when we inspect the network tab, we can see that the same url is used for the request for assets.

Additionally, if we View Source on a page in Vercel, we can see that it is now a relative url.

Conclusion

Vercel offers useful out of the box features such as Deployment Protection and XM Cloud lets us take full advantage of those features with some easy modifications to our headless application. We can now continue to develop and lock down lower environments without risk of exposing what we are working on to the internet.