Launch: hosting and deployment from Contentstack

TL;DR:

• Launch is Contentstack's built-in hosting platform: Git-based deployments, CDN distribution, and content-triggered rebuilds from within the CMS dashboard.
• Map Launch deployments to Contentstack environments so staging content deploys to staging and production content to production.
• Auto-deploy on content publish is valuable for SSG sites but redundant for SSR apps that fetch content on every request.
• For projects needing edge functions, advanced middleware, or complex CI/CD pipelines, external hosting (Vercel, Netlify) may be a better fit.

Contentstack Launch bridges the gap between content management and content delivery by providing a hosting and deployment platform built directly into the Contentstack ecosystem. Instead of configuring a separate hosting provider, connecting it to your CMS via environment variables, and building your own deployment triggers, Launch handles Git-based deployments, CDN distribution, and content-triggered rebuilds from within the same dashboard where editors manage content. For teams that want a streamlined path from content authoring to live website without stitching together multiple services, Launch provides that integrated experience.

What Launch does

Launch is a hosting platform for frontend applications. It takes your source code from a Git repository, runs your build process, and serves the output through a global CDN. The core capabilities are:

• Git-based deployments: Connect a GitHub or GitLab repository, and Launch builds and deploys your application automatically when you push to a configured branch.
• Framework support: Launch supports static site generators (Astro, Hugo, Eleventy), server-side rendered applications (Next.js, Nuxt), and single-page applications (React, Vue, Angular).
• CDN distribution: Built assets are distributed through a CDN for fast global delivery.
• Environment mapping: Launch deployments can be mapped to Contentstack environments, so your staging branch deploys to staging and your main branch deploys to production.
• Content-triggered rebuilds: Launch can automatically rebuild and redeploy your site when content is published to the corresponding Contentstack environment.
• Custom domains: Attach your own domain with automatic SSL certificate provisioning.
• Server-side rendering: For frameworks like Next.js that require a server runtime, Launch provides serverless function execution.

How Launch differs from generic hosting

Vercel, Netlify, and Cloudflare Pages are excellent hosting platforms, and for many projects they are the right choice. Launch differentiates itself through its direct integration with Contentstack:

Integrated deployment triggers: On Vercel or Netlify, triggering a rebuild when content is published requires setting up a webhook from Contentstack to the hosting platform's deploy hook URL. On Launch, this connection exists natively — you configure auto-deploy for a Contentstack environment, and publishes to that environment trigger a rebuild without any webhook setup.

Stack-aware configuration: Launch deployments are associated with a Contentstack stack. The dashboard shows deployment status alongside content management, giving editors and developers a unified view. There is no context-switching between a CMS dashboard and a separate hosting dashboard to understand whether content changes are live.

Environment alignment: Contentstack environments (development, staging, production) map directly to Launch deployments. This makes the relationship between content environments and deployment targets explicit and visible.

Simplified token management: Launch can automatically inject Contentstack delivery tokens and API keys as environment variables, reducing the manual credential management required with external hosting providers.

That said, Launch is purpose-built for content-driven frontend applications. For projects requiring edge workers, advanced middleware, complex routing rules, or extensive serverless function capabilities, dedicated platforms like Vercel or Netlify may offer more flexibility. The choice depends on your project's complexity and your team's preference for integration simplicity versus hosting feature depth.

Setting up a Launch deployment

Setting up Launch involves connecting your Git repository, configuring the build, and mapping environments.

Step 1: Connect your repository

In the Contentstack dashboard, navigate to Launch and create a new deployment. You will be prompted to connect a Git provider (GitHub or GitLab) and select the repository and branch to deploy.

• Repository: Select the repository containing your frontend application.
• Branch: Choose the branch to deploy (e.g., main for production, staging for a staging deployment).
• Root directory: If your frontend code is in a subdirectory of the repository (common in monorepos), specify the path.

Step 2: Configure build settings

Launch needs to know how to build your application:

• Framework preset: Select your framework (Next.js, Nuxt, Astro, Gatsby, etc.). Launch auto-detects the framework in most cases and pre-fills build settings.
• Build command: The command to build your application (e.g., npm run build, yarn build).
• Output directory: Where the build output goes (e.g., .next for Next.js, dist for Vite-based projects, out for static exports).
• Node.js version: Specify the Node.js version your project requires.

Step 3: Set environment variables

Your application needs Contentstack credentials and any other configuration:

NEXT_PUBLIC_CONTENTSTACK_API_KEY=your_api_key
NEXT_PUBLIC_CONTENTSTACK_DELIVERY_TOKEN=your_delivery_token
NEXT_PUBLIC_CONTENTSTACK_ENVIRONMENT=production
NEXT_PUBLIC_CONTENTSTACK_REGION=EU

Launch environment variables support secrets — values are encrypted and not visible after they are saved. For sensitive values like tokens, this is essential.

You can also set environment variables that differ between Launch deployments. Your staging deployment uses a staging delivery token, and your production deployment uses a production delivery token. The same codebase reads from process.env.NEXT_PUBLIC_CONTENTSTACK_DELIVERY_TOKEN, and the correct value is injected based on which deployment is running.

Step 4: Deploy

Once configured, Launch runs the build and deploys the output. You receive a deployment URL (a .contentstacklaunch.com subdomain) where you can verify the build before attaching a custom domain.

Environment mapping

One of Launch's most practical features is mapping deployments to Contentstack environments. This creates a clear relationship between where content is published and where it appears.

A typical setup:

This mapping means:

• When an editor publishes content to the staging environment in Contentstack, the staging Launch deployment can auto-rebuild, and the editor sees the updated content at staging.yoursite.com.
• When content is promoted to production, the production Launch deployment rebuilds, and the live site at yoursite.com reflects the change.

This mirrors the environment promotion workflow covered in Course 3. The difference is that Launch automates the deployment step that you would otherwise manage with deploy hooks on an external platform.

Auto-deploy on content publish

Auto-deploy is the feature that makes Launch feel integrated rather than bolted on. When enabled, publishing content to a Contentstack environment triggers an automatic rebuild of the associated Launch deployment.

The flow:

1. An editor publishes a blog entry to the production environment.
2. Contentstack detects that a Launch deployment is mapped to the production environment with auto-deploy enabled.
3. Launch queues a new build from the configured Git branch.
4. The build runs, fetching the latest content (including the just-published entry) from the Delivery API.
5. The new build is deployed to the CDN, replacing the previous version.

When auto-deploy is appropriate: Static and statically-generated sites (SSG) benefit most from auto-deploy because content changes require a rebuild to appear. A Next.js site using getStaticProps fetches content at build time, so new content is invisible until the site is rebuilt.

When auto-deploy is not needed: Applications using server-side rendering (SSR) or client-side rendering (CSR) fetch content on every request. Content changes appear immediately without a rebuild. For these architectures, auto-deploy on content publish is unnecessary because the frontend always queries the latest content from the Delivery API at render time.

// Next.js: static generation requires rebuild for new content
// Auto-deploy makes sense here
export async function getStaticProps() {
  const query = stack.contentType("product").entry().query();
  const result = await query
    .orderByDescending("published_at")
    .limit(10)
    .find();

  return {
    props: { posts: result.entries },
    // revalidate not used - Launch auto-deploy handles rebuilds
  };
}

// Next.js: server-side rendering fetches on every request
// Auto-deploy is not needed for content freshness
export async function getServerSideProps(context) {
  const query = stack.contentType("product").entry().query();
  const result = await query
    .where("url", context.params.slug)
    .find();

  return {
    props: { post: result.entries[0] },
  };
}

Custom domains and SSL

Launch supports custom domains with automatic SSL provisioning:

1. Add your custom domain in the Launch deployment settings.
2. Create a CNAME record at your DNS provider pointing your domain to the Launch deployment URL.
3. Launch automatically provisions and renews an SSL certificate via Let's Encrypt.

For apex domains (e.g., yoursite.com without www), Launch provides the necessary DNS configuration. The SSL certificate covers both the apex and www subdomain.

Launch limitations and when to use external hosting

Launch is designed for content-driven frontend applications. There are scenarios where a dedicated hosting platform is a better fit:

Complex server-side logic: If your application requires extensive API routes, server-side middleware, or long-running serverless functions, platforms like Vercel or AWS offer more granular control over compute resources and execution limits.

Edge computing: Vercel Edge Functions, Cloudflare Workers, and Netlify Edge Functions provide edge-compute capabilities for request-time logic (geolocation-based routing, A/B testing at the edge, request transformation). Launch focuses on content delivery rather than edge compute.

Advanced routing: Complex rewrite rules, header manipulation, or request-level authentication logic may be easier to implement on platforms with dedicated middleware layers.

Multi-region deployment control: If you need to control which regions your application is served from for data residency or compliance reasons, infrastructure-as-code platforms provide more options.

Existing CI/CD investment: If your team has a mature CI/CD pipeline with GitHub Actions, GitLab CI, or Jenkins, integrating Contentstack with that pipeline via webhooks and deploy hooks may be preferable to adopting Launch.

Decision guide

Deploying a Next.js site: end-to-end example

Here is the complete workflow for deploying a Next.js marketing site to Launch with staging and production environments.

Project structure:

marketing-site/
  src/
    app/
      page.tsx          # Homepage
      blog/
        [slug]/
          page.tsx      # Blog post pages
    lib/
      contentstack.ts   # SDK initialization
  next.config.js
  package.json

SDK initialization using environment variables that Launch provides:

// src/lib/contentstack.ts
import Contentstack from "@contentstack/delivery-sdk";

const regionMap: Record = {
  NA: Contentstack.Region.US,
  EU: Contentstack.Region.EU,
};

export const stack = Contentstack.stack({
  apiKey: process.env.NEXT_PUBLIC_CONTENTSTACK_API_KEY!,
  deliveryToken: process.env.NEXT_PUBLIC_CONTENTSTACK_DELIVERY_TOKEN!,
  environment: process.env.NEXT_PUBLIC_CONTENTSTACK_ENVIRONMENT!,
  region: regionMap[process.env.NEXT_PUBLIC_CONTENTSTACK_REGION || "NA"],
});

Launch configuration for two environments:

With this setup, the deployment lifecycle looks like:

1. Developer pushes code to staging branch - Launch rebuilds the staging deployment.
2. Editor publishes content to staging environment - Launch rebuilds the staging deployment.
3. Editor and QA review at staging.yoursite.com.
4. Developer merges staging to main - Launch rebuilds the production deployment.
5. Editor publishes content to production environment - Launch rebuilds the production deployment.
6. Live site at yoursite.com reflects both code and content changes.

Common mistakes

Common pitfall:

Enabling auto-deploy for a purely SSR application wastes build minutes on every content publish, since SSR already fetches fresh content on each request — auto-deploy is only useful for static generation.

Mistake 1: Enabling auto-deploy for SSR applications

A team configures auto-deploy on content publish for a Next.js application that uses getServerSideProps exclusively. Every content publish triggers a full rebuild, even though the application fetches content on every request and does not need rebuilding for content freshness. This wastes build minutes and creates unnecessary deployment churn. Auto-deploy is useful for static generation; it is redundant for server-side rendering.

Mistake 2: Using the same delivery token for staging and production

A team copies the production delivery token into both their staging and production Launch deployments. Both deployments fetch content from the production environment, so the staging deployment does not show draft or staged content. Each Launch deployment must use the delivery token scoped to its corresponding Contentstack environment.

Mistake 3: Not configuring environment variables as secrets

A team enters their Contentstack management token or third-party API keys as plain-text environment variables. While Launch stores variables securely, marking sensitive values as secrets ensures they are not displayed in the dashboard after initial entry. Treat all tokens as secrets to prevent accidental exposure in screenshots, screen shares, or browser history.