Environments

Production, staging, preview, and custom environments with isolated configuration.

Built-In Environments

Every project has three environments out of the box:

EnvironmentPurposeURLAuto-Deploy
productionLive trafficCustom domain or *.raidframe.appmain branch
stagingPre-deploy testingstaging-*.raidframe.appstaging branch
previewPer-PR environmentspr-42-*.raidframe.appPull requests

Preview Environments

Every pull request gets an isolated environment with its own URL, database, and environment variables.

Opened PR #42: "Add user profiles"

✓ Preview deployed: https://pr-42-my-app.raidframe.app
✓ Database: branched from staging
✓ Environment: inherited from staging

Preview environments are destroyed automatically when the PR is closed or merged. Database branches are cleaned up with them.

Custom Environments

Create additional environments for QA, load testing, demos, or client previews:

rf env create load-test --from production
rf env create demo-acme --from staging
rf env create qa --from staging

The --from flag copies all configuration, environment variables, and optionally databases from the source environment.

Per-Environment Configuration

Environment Variables

rf env set STRIPE_KEY=sk_live_xxx --environment production
rf env set STRIPE_KEY=sk_test_xxx --environment staging

Or in raidframe.yaml:

env:
  shared:
    NODE_ENV: production
    LOG_LEVEL: info
  production:
    STRIPE_KEY: "${secrets.STRIPE_LIVE}"
    DATABASE_POOL_SIZE: "20"
  staging:
    STRIPE_KEY: "${secrets.STRIPE_TEST}"
    DATABASE_POOL_SIZE: "5"

Scaling Rules

services:
  api:
    scaling:
      production:
        min: 4
        max: 40
      staging:
        min: 1
        max: 2
      preview:
        min: 1
        max: 1

Domain Bindings

rf domains add myapp.com --environment production
rf domains add staging.myapp.com --environment staging

Environment Promotion

Push a tested staging deployment to production:

rf deployments promote staging --to production

This deploys the exact same build artifact — no rebuild. The same image that passed your staging tests goes to production.

Branch-Based Auto-Deploy

Configure which branches deploy to which environments:

deploy:
  production:
    branch: main
    auto: true
  staging:
    branch: develop
    auto: true
  preview:
    pull_requests: true
    auto: true

Environment Protection Rules

Require approval before deploying to production:

rf env protect production --require-approval --approvers team-leads
Deploy to production requires approval from: team-leads
Approval requested. Waiting...
✓ Approved by [email protected]
Deploying...

Ephemeral Environments

Clone your entire stack — all services, databases with data, environment variables, cron jobs — into an isolated environment:

rf env clone production --name debug-issue-123 --mask-pii
Cloning production → debug-issue-123
  Services: 3/3 ✓
  Databases: 2/2 ✓ (PII masked)
  Env vars: 14/14 ✓
  Cron jobs: 2/2 ✓

✓ Ready at https://debug-issue-123-my-app.raidframe.app

The --mask-pii flag automatically detects and masks personally identifiable information (emails, names, phone numbers, addresses) in the cloned database.

Destroy when done:

rf env destroy debug-issue-123