# Environments

Environments let one organization keep separate sets of inboxes, phone numbers, API keys, and related workflows. The most common use case is keeping staging and production isolated without creating a completely separate team account.

## Why environments matter

Use environments to:

- keep test traffic away from production resources
- reduce accidental sends from the wrong workflow
- give teams a predictable context for launches, canaries, and QA
- preserve governance consistency while still isolating resource sets

## Typical environment model

Most teams start with something like:

- `default` for day-to-day or initial setup
- `staging` for release rehearsal and integration testing
- `production` for live customer messaging

The exact names matter less than the operating discipline behind them.

## Recommended setup rules

1. Give each environment a clear purpose.
2. Issue API keys per environment and rotate them independently.
3. Name resources so the environment is obvious at a glance.
4. Confirm the active environment before tests, bulk sends, or launch checks.

## Good patterns

- use staging inboxes and phone numbers for CI and pre-release validation
- use production environments for live campaigns and transactional workflows only
- pair environment isolation with [Roles and permissions](/docs/team-permissions/) so production access stays deliberate

## When to use a separate organization instead

Use a separate organization when you need a stronger administrative or identity boundary than one shared organization can provide. Use environments when the same core team needs shared governance with isolated resources.

## Related docs

- [Team accounts](/docs/organizations/)
- [Roles and permissions](/docs/team-permissions/)
- [Testing](/docs/testing/)
- [Custom domains](/docs/custom-domains/)