Environments

Environments represent deployment targets for your prompts. Each project has three default environments: Development, Staging, and Production.

Default Environments

Environment	Typical Use
Development	Local development and rapid iteration. Connect your dev server here.
Staging	Pre-production validation. Mirrors production infrastructure.
Production	Live traffic. Promoted prompts here are immediately served to end users.

Each environment is fully independent. Prompt versions are promoted through environments on your schedule — Development can be on v5 while Production still runs v3.

What "Deployed to an Environment" Means

A deployment is a record saying: for this prompt in this environment, use this version.

Only one version of a prompt can be deployed per environment at a time. Deploying v2 to Production replaces v1 in Production — v1 is not deleted, it is just no longer active in that environment.

SDK instances connected to an environment only see prompts deployed to that environment. A prompt that exists as a draft or is deployed only to Development will not be visible to a Production SDK instance.

The Promotion Workflow

The typical workflow for shipping a prompt change:

1. Create a new draft in the dashboard.
2. Publish the draft to create a new version (e.g., v4).
3. Deploy v4 to Development — your dev environment gets it immediately.
4. Test in Development (your app is connected via rsn_development_xxx).
5. Deploy v4 to Staging — QA and pre-production checks.
6. Deploy v4 to Production — live traffic receives the update within milliseconds.

Each promotion step is a single click in the dashboard and a real-time push to connected SDK instances.

Custom Environments

In addition to the three defaults, you can create custom environments — for example, a dedicated qa or preview environment. Custom environments behave identically to the defaults: they have their own API keys and their own set of active deployments.

Each Environment Has Its Own API Key

API keys are scoped to one project and one environment. When you create a key:

• A rsn_development_xxx key only serves Development deployments
• A rsn_staging_xxx key only serves Staging deployments
• A rsn_production_xxx key only serves Production deployments

Manage keys under Settings > API Keys in your project. Keys can be rotated or revoked at any time — connected SDK instances using a revoked key will be disconnected.

Rolling Back

If a deployment causes a regression, roll back by deploying a previous version:

1. Open the prompt in the dashboard.
2. Go to Version History.
3. Click on the version you want to roll back to.
4. Click Deploy and select the environment.

The previous version is live within seconds — no code change, no redeploy.