Environments

Every project in VersionR has three environments: development, staging, and production. Each environment maintains its own independent active version pointer.

How environments work

Deploying a version to staging has no effect on production. Each environment is a completely independent slot — you can have:

• development → version 3
• staging → version 5
• production → version 4

Changes flow through environments deliberately, not automatically.

Intended workflow

Edit in Draft
     ↓
Deploy to development  →  Test locally with SDK
     ↓
Deploy to staging      →  Review with team / QA
     ↓
Deploy to production   →  Live to users

You are never required to deploy through each stage in order — you can deploy directly to production from any version. The stages exist to give your team a checkpoint, not to enforce a pipeline.

Selecting an environment in the SDK

Pass env to every SDK call to specify which active version to fetch:

// Fetch the staging version during review
const prompt = await pd.get('my-prompt', { env: 'staging' })
 
// Fetch the production version in your live app
const prompt = await pd.get('my-prompt', { env: 'production' })

The env value must match one of 'development', 'staging', or 'production'.

API keys per environment

Each environment has its own API key. A key issued for staging cannot read production prompts, and vice versa. This is enforced server-side.

Use separate environment variables for each:

VERSIONR_DEV_KEY=pd_dev_...
VERSIONR_STAGING_KEY=pd_stg_...
VERSIONR_PROD_KEY=pd_prd_...

Then select the right key based on your deployment environment:

const pd = new VersionR({
  apiKey: process.env.VERSIONR_PROD_KEY,
})

Undeployed environments

If an environment has no active version (e.g. you’ve never deployed to staging), the SDK throws a VersionRError with code NO_ACTIVE_VERSION. This is intentional — fetching from an environment that was never set up should fail loudly.