MailSlurp logo
Search documentation

Environments

Isolate staging, production, and workflow-specific resources inside one MailSlurp organization.

View MarkdownAgent setup

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.

  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 so production access stays deliberate

Restrict organization access by role or user

When an organization is granted access to an environment, the grant can apply to all organization users or be restricted to selected organization roles or users.

Use role restrictions when your identity provider assigns MailSlurp roles through SAML. For example, map an Entra app role or group claim to a PTEST user role, then restrict the PTEST environment grant to that role. Users mapped only to a DEV role can remain in the same organization without seeing or switching into PTEST.

For step-by-step provider examples, see Entra SAML role mapping and Google Workspace SAML role mapping.

Use user restrictions for small exceptions, such as a named release owner who needs temporary access to a locked environment.

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.