Launch FAQs

No. Your last successful deployment will remain active until it is replaced by a subsequent successful deployment. However, redeploying your site will clear the CDN cache for your site, so previously cached pages will be served as uncached requests the first time they are accessed.

Yes. Custom domains may be added and configured in each environment’s settings.

Yes. Launch deploys server-side functionality as serverless functions. This includes SSR-rendered pages, and Cloud Functions.

Yes. To deploy a static site, follow the process specified in your framework code for static site generation (SSG) rendering.

Yes. You can execute your code in proximity to your user’s location before a request is processed using Edge Functions in Contentstack Launch.

Yes. The Log Targets feature in Contentstack Launch allows you to forward the logs produced by Launch Cloud Functions or by Launch-supported frameworks to third-party monitoring services that support GRPC OTLP endpoint.

You can find the frameworks supported by Launch in the Launch Framework Support Matrix.

Launch runtime operates in a read-only file system, except for the designated /tmp directory, which facilitates write operations. The /tmp directory is a temporary file system accessible to every Launch serverless runtime, offering up to 500 MB of storage.

Note: The data stored in /tmp is non-persistent and is automatically deleted upon request completion.

Yes. Automate includes triggers and actions for common Launch activities. Launch also includes deploy hooks functionality, allowing you to trigger rebuilds via a URL. Launch can also use the Marketplace app to set up an SSO at the edge.

Launch technical support is offered through the same technical support channels used for all other Contentstack products.

Launch is available in AWS NA, AWS EU, AWS AU, Azure NA, Azure EU, GCP NA, and GCP EU regions.

Depending upon your specific architecture and change process, migrating your existing site to Launch can be achieved with zero or minimal downtime.

Launch currently supports deploying sites via GitHub, BitBucket, and direct zip file uploads. GitLab support will be available shortly.

Yes. Launch can be configured to automatically redeploy when code updates are committed in GitHub and when webhooks are accessed. Launch commands are also available via Contentstack’s CLI.

Yes. Automatic deployments can be configured in your environment’s settings screen.

Yes. Each Launch project includes 5 environments by default, which you can use to deploy environments for staging, testing, content review, and more.

Launch features deployment and server logs to help you troubleshoot deployments and functionality. Serverless functions can also be tested locally.

If you wish to deploy sites to Launch directly from GitHub, then you must authenticate with your GitHub account. However, Launch also supports deployments directly from a zip file upload, which does not require GitHub access.

Bulk site deployments can be achieved via the CLI and through local scripting.

Launch is a front-end hosting and deployment platform for websites built on the Contentstack CMS instantly, but it cannot run Docker containers.

Please refer to this documentation, for more information about Docker containers and why Launch does not support them.

Currently, Launch supports Node.js versions 18.x (discontinued as of August 1, 2025), 20.x and 22.x for running website builds during deployment. For more information, please refer to the supported Node.js versions.

Warning: Support for Node.js version 18 is discontinued for Launch as of August 1, 2025. Update to a supported Node.js version to avoid disruptions in your projects.

Launch cannot be used for native mobile apps, such as those installed from an app store. However, you can use Launch to host mobile-friendly and responsive websites or web apps. Additionally, it can be used to support backend needs, such as building APIs that your mobile app can access.

Launch can forward up to 1000 logs in a single request.

Caching reduces latency and load times by storing copies of your content closer to your users on CDN servers. This results in faster page loads, improved user experience, and reduced load on your origin servers.

Caching duration depends on the Cache-Control headers you set. You can specify caching durations using headers like max-age and stale-while-revalidate.

Yes. You can control caching behavior by setting specific HTTP headers in your responses.
Refer to the Dynamic Content with Cache Headers section in the Caching Guide for Contentstack Launch doc for details.

No. Launch does not support Next.js ISR or native caching APIs like revalidatePath or revalidateTag. For more details, see Next.js limitations.

Use the following header to disable caching:
Cache-Control: no-store

Refer to the Purging Cache section in the Caching Guide for Contentstack Launch doc for details.

It is generally not recommended to layer multiple CDNs, as this could lead to cache conflicts and unpredictable behavior.

You can monitor caching behavior using response headers such as x-cache or cf-cache-status. A value of HIT indicates that the content was served from the cache, whereas MISS indicates that it was fetched from the origin.

Sensitive or private data should never be cached. Always ensure sensitive data responses have caching disabled (no-store or no-cache) headers set explicitly.

Visit our dedicated Next.js on Launch Documentation for more details.

By default, 404 and error pages are not cached by Launch’s CDN, even if Cache-Control headers are present. This is a platform-level behavior to ensure error pages are always revalidated. Identify known bad routes and handle them gracefully at the edge using Launch Edge Functions.

No. Launch does not support the native data cache feature of the Next.js App Router (e.g., fetchCache, revalidatePath, revalidateTag) due to its serverless and read-only file system architecture.

• Use SSR with Cache-Control headers: Cache API responses at the CDN level using Cache-Control headers to increase the cache-hit ratio and enable on-demand cache revalidation with Automate.
  Cache-Control: public, s-maxage=86400, stale-while-revalidate=60
• Cache API requests in a framework-agnostic way: Check out the GitHub example that caches Contentstack Management API responses to reduce rate-limiting issues.

Launch uses Cloudflare as its CDN. Caching external URLs can apply, but only if the external URL is served through Cloudflare and returns cacheable Cache-Control headers. If the external origin is hosted on a different CDN or server and lacks cacheable headers, the response will not be cached.

No. Each request is handled by a stateless function instance that may not retain memory between invocations. This implies:

• Any data stored in memory—such as variables, objects, or in-process caches—is not guaranteed to persist beyond a single request.
• You should opt out of in-memory caching supported by some libraries, such as the Contentstack SDK, which can optionally maintain a local cache to help with rate limiting and performance.

Check your website's HTML for the presence of the Event Tracking <script> tag. If the tag is present, Event Tracking is active.
For example: <script async="" src="https://c.lytics.io/api/tag/*/latest.min.js"></script>

Yes. If your application uses ETag-based browser-side caching, you must redeploy your site. This ensures that the Event Tracking script is correctly delivered to users.

If the Real-Time Event <script> tag is missing from the HTML, Event Tracking is disabled.

Changes typically take effect within 5 minutes of updating the settings.

A mandatory redeploy is required to activate the Event Tracking (Lytics) feature on your website due to browser caching (ETag behavior).

A mandatory redeploy is required to deactivate the Event Tracking (Lytics) feature on your website due to browser caching (ETag behavior).

No. Data collection begins only after users provide explicit consent. To collect user-specific data, you must configure a custom tag or build a custom consent modal. When the user accepts, Real-Time User Event Tracking starts for that session.

This is due to how <NuxtLink> handles client-side navigation. To resolve this, use standard <a> tags instead.

Learn more in the Nuxt.js on Launch guide.

Focus on high-traffic and frequently accessed pages, especially those updated regularly. These include landing pages, key product pages, dynamic content, and essential resources that must load quickly.

No, Cache Priming seamlessly integrates with your current caching configuration. It enhances performance by preloading content during deployment without overriding existing cache rules or policies.

Yes, Cache Priming supports multi-environment deployments, ensuring optimized caching across staging, production, and other environments without manual intervention.

Cache Priming works alongside cache revalidation mechanisms, updating content based on predefined policies or upon new deployments.

Yes, Cache Priming optimizes both static and dynamic content. It preloads frequently accessed dynamic pages that follow predictable update patterns while ensuring static pages load instantly.

Configure Cache Priming by specifying key URLs in launch.json and enabling the cache priming toggle from the UI. For detailed instructions, refer to the Cache Priming document.

You can use Automate to purge the cache for the URL and remove the URL from the Cache Priming list. The cache will gradually invalidate outdated content based on your CDN’s expiration policies.

Cache Priming is designed for globally accessible content and respects security policies, geo-restrictions, and IP limitations:

• Geo-Specific Content: Priming is only effective where regional content is accessible. If a page is restricted by geography, users outside those regions may not benefit.
• Security & IP Restrictions: Cache Priming does not override authentication or IP-based restrictions. Websites with strict access controls must explicitly allow Contentstack IPs for priming to be effective.

Cache Priming can preload API responses, making frequently requested data instantly available. This reduces response times and backend load.

For major content updates, use Cache Priming alongside cache revalidation strategies to serve fresh content without requiring a full cache purge.

To learn how to revalidate already cache-primed paths, refer to the Revalidate CDN Cache Launch document.