Environments

Shipping a workflow change straight to production is risky. Environments give you a safe path from development to live traffic by letting each stage point to a different revision.

Environment Model

Scout has three environments, each mapped to a workflow revision:

• development: Where you build and iterate. No real user traffic, no pressure.
• staging: Your pre-production gate. Test with realistic inputs before anything goes live.
• production: Live traffic. Only promote here once staging confirms the change behaves correctly.

You control which revision each environment points to. Changing an environment doesn’t change your workflow — it just changes which revision that environment runs.

Deployment Flow

1. Build and test your changes in development using Console
2. In History, name the revision and note what changed
3. Promote that revision to staging
4. Run validation tests against staging using realistic inputs
5. Promote to production once staging passes

Targeting Environments in the API

When you call a workflow via API or SDK, you can specify which environment to run:

curl -X POST "https://api.scoutos.com/v2/workflows/{workflow_id}/execute?environment=staging" \
  -H "Authorization: Bearer $SCOUT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": {
      "user_message": "Summarize last week's activity"
    }
  }'

Switch environment=staging to environment=production or environment=development depending on what you need. This is useful for running automated checks against staging before a production promote.

Diff Before Deploy

Before promoting to production, check what actually changed in the revision diff:

• Blocks view: High-level structure and connection changes — use this for a quick sanity check
• Code view: Detailed JSON-level changes — use this when something subtle might have shifted in block config

If the diff looks larger than expected, investigate before promoting.

Rollback

If a production deploy degrades output quality or reliability:

1. Open History and find the last known good revision
2. Promote that revision back to production
3. Confirm recovery in Logs
4. Fix forward in development — don’t patch production directly

Next Steps

• History: Name revisions and manage deployment state
• Logs: Verify deployment health after a promote
• Running Workflows: Execute workflows with explicit environments

Built with ❤️ by Scout OS