> ## Documentation Index
> Fetch the complete documentation index at: https://docs.subscriber.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments

> Keep testing separate from the emails your real users get.

An environment is a separate set of subscribers, workflows and integrations inside a workspace. Use one for testing so you never email real people by accident.

Every workspace starts with **Production**. Add as many others as you like, such as staging or one per developer. Only production counts towards [your plan](https://docs.subscriber.dev/plans.md).

## Create and switch environments

> [tab] CLI
>
> ```bash theme={null}
> subscriber environments create Staging
> subscriber environments list
> subscriber environments use <environmentId>
> ```
>
> Every command runs against the current environment. To run one command against another, add `--environment <environmentId>`.

> [tab] TUI
>
> Choose a workspace, then pick an environment, or press `n` to create one.

> [tab] API
>
> Each API key belongs to one environment, so it can't create environments. Create them with the CLI or your agent, then create a key in each: `subscriber keys create "Acme app" --environment <environmentId>`.
>
> Requests made with a key use its environment, so you never pass the ID.

Tell your [agent](https://docs.subscriber.dev/mcp.md) which environment to use, such as "use staging".

## What's separate

Nothing is shared between environments. A new environment starts empty, with no subscribers, workflows or integrations.

| Each environment has its own | So in a new one |
| - | - |
| Subscribers | Add test subscribers, such as your own email. |
| Workflows | Create the workflows you want to test. |
| Integrations | Connect an email provider. A test inbox like Mailtrap works over [SMTP](https://docs.subscriber.dev/integrations/smtp.md). For [Stripe](https://docs.subscriber.dev/integrations/stripe.md), use a test-mode key and webhook. |

## Moving from staging to production

Nothing copies workflows between environments, so keep each workflow's JSON in your repo and create it in each environment:

```bash theme={null}
subscriber workflows create --file welcome.json --environment <stagingId>
subscriber workflows create --file welcome.json --environment <productionId>
```

After a change, run `workflows update <workflowId> --file welcome.json` in each environment. Your agent can do the same: "Copy the welcome workflow from staging to production."


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.