---
title: "Environments"
description: "Safely iterate on content models without affecting production content."
category: "concepts"
audience: developers
lastUpdated: "2026-09-17T06:13:24.000Z"
---
Environments allow you to modify content models without affecting production content. You can test model changes against your content in isolation before pushing the changes to production.
> Environments are a Platinum and Enterprise plan feature available as a **paid add-on**. To enable this feature, vist our [Pricing page](https://prismic.io/pricing) and select 'Contact Us'.
An environment clones content from your production repository into a new repository, including:
* Content models ([page types](https://prismic.io/docs/content-modeling.md#page-types), [slices](https://prismic.io/docs/slices.md), and [custom types](https://prismic.io/docs/content-modeling.md#custom-types))
* Pages
* Media files
The following are **not** cloned into new environments:
* Users (user permissions are shared between environments)
* [Integration](https://prismic.io/docs/fields/integration.md) field catalogs (catalogs are shared between environments)
* Webhooks
# How to create an environment
1. **Open your environment settings**
Navigate to your Prismic repository and go to **Settings** > **Environments**.
You must be the repository owner or have admin rights to access the Environments page.
2. **Create an environment**
In the **Environments** section, create an environment using the following values:
| Field | Value |
| ---------------------------------- | ---------------------------------------------------------------------------- |
| **Name** | The name that content writers see. It also determines the environment's URL. |
| **Choose an environment to clone** | The base environment used to copy content and settings. |
Click **Create a new environment** after filling in the values.
3. **Sync content**
Prismic will automatically start to clone content from the selected base environment into the new environment.
You can access the new environment once everything is synced.
# Local development
Use the [Prismic CLI](https://prismic.io/docs/cli.md) to work with an environment from your project.
1. **List your environments**
```sh
npx prismic env list
```
2. **Select an environment**
Set the active environment with its domain:
```sh
npx prismic env set example-prismic-repo-staging
```
Model commands like `pull` and `push` now target the environment instead of production. Print the active environment with `npx prismic env active`.
To target an environment once without changing the active environment, pass `--repo` with its domain to a command instead.
3. **Change your models**
Pull the environment's models, edit them, and push your changes as usual:
```sh
npx prismic pull
npx prismic push
```
To go back to the production repository, reset the active environment:
```sh
npx prismic env unset
```
## Fetch content from an environment
The `env set` command saves the environment's domain to a variable in `.env.local`. The variable name depends on your framework:
* **Next.js**: `NEXT_PUBLIC_PRISMIC_ENVIRONMENT`
* **Nuxt**: `NUXT_PUBLIC_PRISMIC_ENVIRONMENT`
* **SvelteKit**: `PUBLIC_PRISMIC_ENVIRONMENT`
Read the variable in your Prismic client so that your development website fetches content from the environment. Your production website keeps using the production repository.
* **Next.js:**
```ts filename=prismicio.ts
export const repositoryName = // [!code ++]
process.env.NEXT_PUBLIC_PRISMIC_ENVIRONMENT || prismicConfig.repositoryName; // [!code ++]
```
* **Nuxt:**
**No code changes are necessary**. `@nuxtjs/prismic` reads the variable automatically.
* **SvelteKit:**
```ts filename=src/lib/prismicio.ts
import { env } from "$env/dynamic/public"; // [!code ++]
export const repositoryName = // [!code ++]
env.PUBLIC_PRISMIC_ENVIRONMENT || prismicConfig.repositoryName; // [!code ++]
```
# Push changes to production
Once your content model changes have been tested in your development environment, push them to your production repository.
> Be sure to consider how [existing content will be impacted](https://prismic.io/docs/content-modeling.md#impact-of-pushing-changes) by your content model changes. Test changes in a development environment before pushing to production.
1. **Return to production**
Reset the active environment. The CLI removes the variable from `.env.local`, and your development website fetches production content again.
```sh
npx prismic env unset
```
2. **Push to Prismic**
Commit your model changes, then push them:
```sh
npx prismic push
```
The Page Builder will now recognize your changes.
# Resync content
Over time, an environment's content will diverge from the production repository. You can resync content and its models from the production repository at any time.
We recommend resyncing at the start of each website development cycle, such as starting to add a new [slice](https://prismic.io/docs/slices.md) or website feature.
> **Important**
>
> Resyncing will overwrite all existing development content and its models using the production versions.
1. **Open your environment settings**
Navigate to your Prismic repository and go to **Settings** > **Environments**.
You must be the repository owner or have admin rights to access the Environments page.
2. **Resync the environment**
In the **Environments** section, locate your environment and click its **Resync** button.
Prismic will start to sync content from the base environment into your environment.
# FAQs
## Should I use environments for staging content?
No. Environments are only meant for making changes to content models without endangering the production repository's content.
**We recommend that content writers stay on the production repository to author new content**. Content writers can use [releases](https://prismic.io/docs/releases.md) and [previews](https://prismic.io/docs/previews.md) to review content on the front-end before publishing.
## Why is content missing after pushing changes?
In most cases, this happens because a [page type](https://prismic.io/docs/content-modeling.md#page-types), [custom type](https://prismic.io/docs/content-modeling.md#custom-types), or [field](https://prismic.io/docs/fields.md)'s API ID was renamed. Changing an API ID is effectively the same as removing the model (along with the model's content) and adding a new one with the updated API ID.
If you need to rename a model, we recommend not editing its API ID and renaming its label instead. Existing content will be retained and content writers will see the new label.
We recommend testing content model changes in a development environment to protect your production content.
[Learn more about the impact of pushing changes](https://prismic.io/docs/content-modeling.md#impact-of-pushing-changes)
## Can I use "development" endpoints for an integration field?
Yes. Read the following guide to understand how the integration field and environments can work together and how you can configure a different integration endpoint on your cloned environments.
[Learn how to use integration fields with environments](https://community.prismic.io/t/how-to-configure-a-different-integration-field-endpoint-in-a-prismic-development-environment/5444)