Click Services and go to Network & Content Delivery > CloudFront.
Click Create a CloudFront distribution.
The following table gives a high-level overview of the required cache policy, origin request policy, and response headers policy for serving the JavaScript SDK:
Name of your cache policy, for example,jssdk-caching-policy.
Description
Add your policy description here.
TTL settings
Field
Setting
Notes
Minimum TTL
0 (in seconds)
Ensures the no-store header is respected.
Maximum TTL
31536000 (in seconds)
Allows CloudFront to use the Cache-Control value from origin if it is greater than 0.
Default TTL
300 (in seconds)
Used when origin does not include Cache-Control headers.
For the RudderStack CDN, CloudFront is configured with a long default TTL (one year) to maximize cache efficiency, and rely on invalidations during releases to refresh content.
RudderStack recommends configuring the prescribed TTLs settings when setting up a custom domain. For the reasoning behind these recommendations, see the AWS documentation.
This ensures that the custom domain’s CloudFront distribution always respects the origin Cache-Control and Age headers as the TTLs defined by RudderStack. Since these headers are managed by RudderStack, they may be updated in the future to improve reliability and correctness.
In cases where you need to control browser-side caching policies instead of relying solely on RudderStack’s origin settings, you can configure a CloudFront response headers policy with the Override origin option enabled for Cache-Control headers.
If you are using a different cloud provider for your custom domain, make sure to set the maximum TTL value to 300, that is, 5 minutes.
Cache key settings
Field
Setting
Headers
None
Query strings
All
Cookies
None
Compression support
Select both Gzip and Brotli.
Then, click Create to generate the cache policy.
Origin request policy settings
Create a new origin request policy with the following settings:
Field
Setting
Name
Enter the origin request policy name, for example, jssdk-origin-request-policy
Paste the following snippet in your website’s <head> section and update the URL from:
varsdkBaseUrl="https://cdn.rudderlabs.com";
to:
varsdkBaseUrl="https://<YOUR_CUSTOM_DOMAIN>"
Replace <YOUR_CUSTOM_DOMAIN> in the above snippet with your domain URL.
Make sure that the distribution settings are configured correctly and no paths are blocked. Otherwise, the events may not flow through correctly.
For example, paths like <YOUR_CUSTOM_DOMAIN>/v3/modern/plugins/rsa-plugins.js and <YOUR_CUSTOM_DOMAIN>/3.12.0/modern/plugins/rsa-plugins.js should both be accessible. Otherwise, the SDK may not be able to load properly.
If you’re loading the JavaScript SDK asynchronously, paste the snippet in your website’s <head> section and update the URL from:
Replace <YOUR_CUSTOM_DOMAIN> in the above snippet with your domain URL.
NPM
Since you have used the NPM module for integrating the SDK directly into your application, there is no configuration required for serving the core SDK.
Additional configuration
Note that this section is only applicable for:
npm installations
Customized CDN installations not following the default directory structure that the SDK uses to automatically fetch the plugins and device mode destinations.
This section covers some additional configuration required for loading the device mode destinations and plugins:
Configure the load API option for plugins as follows if you are not using the @rudderstack/analytics-js/bundled package that bundles all the plugins into the SDK package.
The JavaScript SDK automatically replaces /v3 in the configured URL with the current SDK version to load the most compatible integrations and plugins. So, make sure to proxy the whole RudderStack CDN domain instead of specific paths.
For example, if you specify https://<YOUR_CUSTOM_DOMAIN>/v3/modern/js-integrations for loading device mode destinations, then you might see the network request going to https://<YOUR_CUSTOM_DOMAIN>/3.23.0/modern/js-integrations/<DEST_NAME>.min.js to load the destination integration SDKs.
Replace <YOUR_CUSTOM_DOMAIN> in the above snippet with your domain URL.
Use custom SSL certificates
To use a custom domain for your use case, you can request or import an SSL certificate with your CDN provider. Note that this is an optional setting.
To use the AWS Certificate Manager with CloudFront, choose the relevant ACM/IAM certificate in the Custom SSL certificate field:
You can choose your subdomain or use a wildcard domain *.yourdomain.com to set up multiple subdomains.
The AWS Certificate Manager will guide you through the verification by email or DNS TXT records. You will be able to choose your own domain for SSL certificates once verified.
Custom request header for GCP external load balancer
Can I overcome ad blockers by serving the JavaScript SDK on my domain?
Many popular ad blockers block specific SDK-related downloads and API calls based on the domain name and URL. You can serve the SDK on your CDN to circumvent this issue.
This site uses cookies to improve your experience while you navigate through the website. Out of
these
cookies, the cookies that are categorized as necessary are stored on your browser as they are as
essential
for the working of basic functionalities of the website. We also use third-party cookies that
help
us
analyze and understand how you use this website. These cookies will be stored in your browser
only
with
your
consent. You also have the option to opt-out of these cookies. But opting out of some of these
cookies
may
have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This
category only includes cookies that ensures basic functionalities and security
features of the website. These cookies do not store any personal information.
This site uses cookies to improve your experience. If you want to
learn more about cookies and why we use them, visit our cookie
policy. We'll assume you're ok with this, but you can opt-out if you wish Cookie Settings.