Documentation

Environments & Content Versions

Environments in SleekCMS are labels — named aliases that point to a version of your content. When you publish content to an environment, the alias updates to point to the current content snapshot. When your frontend fetches content from that environment, it gets the snapshot the alias points to.

This is how you control which version of your content is live. You edit freely, and nothing changes on your production site until you explicitly publish to the production environment.

This page covers how environments work, how aliases resolve to content versions, CDN caching behavior, and how to configure your client to get fresh content after a publish.

How Environments Work

An environment is a label you create — production, staging, qa, or any name that fits your workflow. Each label is an alias that points to a specific content version. When you publish content to an environment, the alias updates to point to the latest content snapshot at that moment.

The content itself isn't duplicated. Publishing to an environment doesn't create a copy — it moves the alias pointer. The production label now resolves to the content as it exists right now. If you publish again later after making edits, the alias moves again to the new snapshot.

The latest Environment

Every site has a built-in latest environment. This is not a label you create — it always exists and always points to the current state of your content. Every edit, every save, every change is immediately reflected in latest.

latest is useful for previewing content during editing, for internal review, and for development. It is not typically used for production, because it updates on every change — including half-finished edits.

Named Environments

Named environments are the labels you create for controlled publishing. You might have one (production) or several (staging, production, qa). Each is an independent alias that only moves when you explicitly publish to it.

The simplest setup is a single production environment. You edit content, review it via latest, and when it's ready, publish to production. Your live site reads from production and only sees the content you've promoted.

A multi-environment setup adds stages:

latest — Every edit is reflected here immediately. Use for in-progress work and real-time previews.

staging — Publish here when content is ready for review. A staging site reads from this environment, showing stakeholders exactly what will go live.

production — Publish here when staging is approved. Your live site reads from this environment.

Each environment is just a label pointing to a snapshot. You can have as many as your workflow requires.

Publishing to an Environment

Publishing is a deliberate action. You select an environment from your list of labels, and SleekCMS updates that alias to point to the current content. Optionally, you also select a trigger target to notify an external system.

After publishing, the environment's alias resolves to the new content version. Any frontend fetching from that environment gets the updated content on its next request (subject to caching — see below).

Publishing to one environment does not affect others. You can publish to staging without changing what production points to. Each alias moves independently.

Fetching Content by Environment

Your frontend specifies which environment to fetch from when creating a client or calling the API. The environment name appears in the API URL path:

GET https://pub.sleekcms.com/{site-id}/production
GET https://pub.sleekcms.com/{site-id}/staging
GET https://pub.sleekcms.com/{site-id}/latest

With the client library:

// Fetch from the production environment
const client = await createSyncClient({
  siteToken: 'your-site-token',
  env: 'production'
});

// Fetch from staging
const stagingClient = await createSyncClient({
  siteToken: 'your-site-token',
  env: 'staging'
});

If env is not specified, the client defaults to latest.

→ Content API

CDN Caching and resolveEnv

Content served through the API is cached on a CDN for fast delivery. The cache key is based on the environment name. This means that after you publish to an environment — updating the alias to a new content version — the CDN may still serve the previous cached version until the cache expires.

The resolveEnv option on the client solves this. When enabled, the client resolves the environment alias to its underlying version tag before fetching content. Because the version tag changes every time you publish to that environment, the resolved URL is different, producing a new cache key that bypasses the stale cache.

const client = createAsyncClient({
  siteToken: 'your-site-token',
  env: 'production',
  resolveEnv: true
});

Without resolveEnv — The client fetches from /production, which may return a cached response from the CDN even after you've published new content. The cache will eventually expire and refresh, but there's a delay.

With resolveEnv — The client first resolves production to its current version tag (e.g., mlciujgn), then fetches from that tag. After a publish, the tag changes, producing a different URL that the CDN hasn't cached yet. The result is fresh content immediately after publishing.

The tradeoff is latency. With resolveEnv enabled, every request makes an extra call to resolve the alias before fetching content. For server-side rendering where freshness matters on every request, this is usually worth it. For static site generation where you build once, the extra call happens only at build time and is negligible.

// SSR — use resolveEnv for fresh content on every request
const client = createAsyncClient({
  siteToken: 'your-site-token',
  env: 'production',
  resolveEnv: true
});

// SSG — resolveEnv is optional, runs once at build time
const client = await createSyncClient({
  siteToken: 'your-site-token',
  env: 'production'
});

→ @sleekcms/client

Common Patterns

Single Environment (Simple)

One production environment. Edit content, review via latest, publish to production when ready. Your live site points to production.

This works well for small teams and sites where content goes through minimal review before going live.

Staging and Production

Two environments. Publish to staging for review, then publish to production when approved. A staging site reads from staging, the live site reads from production.

This adds a review gate without adding complexity. Stakeholders preview on staging, approve, and then the same content is promoted to production.

Per-Feature or Per-Campaign Environments

Create environments for specific purposes — campaign-launch, redesign, holiday-content. Publish to them when preparing content for specific initiatives, and point preview URLs at each one for review. When the initiative goes live, publish to production.

These environments are just labels. Create them when you need them, and they cost nothing to maintain. The content isn't duplicated — only the alias pointer exists.

What's Next