Custom Environments: Ship Customer Messaging like you Ship Code

Ship Customer Messaging like you Ship Code

Courier workspaces now support fully isolated custom environments. Name them whatever makes sense for your team (dev, staging, QA, production), give each one its own integrations and templates, and promote assets between them when you're ready.

Previously, you got two environments: Production and Test. That worked for simple setups, but it didn't reflect how most teams actually build software. If you had separate staging and QA phases, or multiple squads iterating on different messaging flows, you were cramming all of that into a single Test environment. That's over.

What custom environments give you

Each environment is a complete, isolated workspace. Templates, brands, tags, subscription topics, integrations, journeys, API keys, and logs all belong to that environment alone.

Full isolation between environments

Nothing leaks between environments. Changes to templates in your dev environment don't touch staging. A new integration configuration in QA doesn't affect production. Journeys, notification logic, and provider configs are all scoped to the environment they belong to. Each environment has its own message logs and metrics, so you always know exactly what happened where.

Your naming, your workflow

Production stays Production. Everything else is yours to name. Rename the default Test environment to "Development," create a "Staging" environment, add "QA" for your testing team. The names map to your process, not ours.

Per-environment integrations

Each environment gets its own integration configurations. Connect your staging SendGrid account to your staging environment and your production account to production. No more shared integrations with test overrides bolted on. Cleaner setup, fewer surprises.

Migrate assets in any direction

Move templates and their dependencies (brands, tags, subscription topics) between any two environments. Promote from dev to staging, staging to production, or roll something back from production to QA for debugging. The migration flow copies all dependencies automatically so nothing breaks.

What you can build

• A dev-to-production pipeline. Build templates and journeys in dev, validate in staging, and promote to production. The same flow you use for code, now applied to your messaging.
• Team-based sandboxes. Give your onboarding squad, billing team, and marketing team each their own environment to iterate without stepping on each other. When a flow is ready, promote it to production.
• Isolated QA testing. QA gets a dedicated environment with its own provider credentials. Test sends hit sandbox accounts, logs stay separate, and you validate the full messaging lifecycle before anything reaches real users.

Each of these used to require workarounds: shared Test environments, naming conventions to avoid collisions, or separate Courier workspaces entirely. Now it's a first-class feature.

Available now

Custom environments are available today on all plans.

1. Open your workspace settings and navigate to Environments.
2. Create a new environment and give it a name.
3. Configure integrations, build templates, and start sending.

Or start with the docs to see the full details.

Already using Test and Production? Nothing changes for you unless you want it to. Your existing environments work exactly as before. You can rename your Test environment and create additional ones whenever you're ready.