Using Content Environments to Separate Staging from Production

You added a new required field to a content type in production and your Next.js build failed three minutes later because existing entries did not have that field populated. Content environments prevent exactly this. They work like Git branches for your CMS: you can branch off production, make schema changes, test with real content, and merge only when everything is confirmed working.

What Content Environments Give You

Each ContentGrid environment is a full copy of your schema. Entries are scoped to an environment by default, so changes in staging never affect production content. You can:

• Add or remove fields from content types without touching production.
• Test migration scripts against a real schema copy before running on production data.
• Let editors preview new content structures before the feature ships.
• Roll back by simply discarding the environment if something goes wrong.

Creating a Staging Environment

In the ContentGrid dashboard, go to Settings → Environments and click New Environment. Choose Clone from production to copy the current schema. Name it staging. ContentGrid gives you a separate API endpoint for each environment. Store this endpoint in your environment variables as CONTENTGRID_ENV_STAGING.

For Vercel deployments, set the staging API endpoint in your preview environment variables. Vercel preview deployments will automatically use the staging CMS environment. Your production deployment uses the production endpoint. This means every pull request preview points at staging content automatically.

Wiring Environments to Your Deploy Pipeline

Set up three environments to match a typical workflow:

• production: live site, used by your main Vercel deployment.
• staging: mirrors production schema, used by Vercel preview deployments.
• development: used by local development, can be reset freely.

Store each endpoint in a separate environment variable and switch between them using NODE_ENV or a custom CMS_ENV variable. Your ContentGrid SDK initialisation takes the endpoint as a parameter, so switching is one line of config.

Merging Schema Changes to Production

When your schema change is tested and content is ready, use the ContentGrid CLI to apply the diff:

• Run contentgrid env diff staging production to see exactly what will change.
• Review the diff, especially any field deletions, which are destructive.
• Run contentgrid env promote staging production to apply schema changes.
• Migrate any content entries that need the new fields before your new front-end code deploys.

Environments cost nothing extra on ContentGrid: you can create as many as your workflow needs. Most teams settle on two or three. The key discipline is never making schema changes directly in production. Branch first, test, then promote.