Skip to main content
An Environment in Reqflo describes the system target for a run — the set of service-level configuration values (base URLs, environment-specific config, service credentials) that tell the journey where to send its requests. You choose an environment each time you run a journey.

When to use it

Select an environment whenever you run a journey. Different environments let you run the same journey against sandbox, staging, and production systems without changing the journey itself.

Key concepts

  • Environment — a named configuration that provides system-level values per service: base URLs, environment flags, and other service-level settings. Environments are managed in Admin → Service environments.
  • System target — what an environment represents. Choosing staging points the journey’s requests at staging endpoints; choosing production points them at production.
  • Environment values — values supplied by the environment at run time. They’re injected into steps that reference them, alongside run inputs and case values.
  • Combining with cases and run inputs — environments, cases, and run inputs are separate and combine at run time. The environment answers where; the case answers what data; run inputs supply anything not covered by the case.
  • Sandbox mode — a temporary, flexible override mode that lets you experiment with full value control without changing saved configuration. Useful for ad-hoc testing and debugging. Teams who want reusable configurations should prefer cases and explicit value sources over sandbox overrides — sandbox mode is intended for temporary use.

How it works

When you start a run (in Run mode, Runbook, or via the CLI), you choose:
  1. Environment — which system target to run against.
  2. Case (optional) — which saved value configuration to use.
  3. Run inputs — any values not covered by the case.
Reqflo resolves values in this order: run inputs and case values take precedence over environment defaults where they overlap. See Value resolution order for the full precedence rules. Sandbox mode: In the editor, you can switch to sandbox mode to freely override any value for the current session. Sandbox overrides are not saved to the journey or to any case — they’re temporary. When you finish experimenting, switch back to a case-based configuration.
If you find yourself making the same sandbox overrides repeatedly, save them as a case instead. Cases are reusable; sandbox overrides are not.

Examples

A journey with three environments:
EnvironmentBase URLNotes
sandboxhttps://api-sandbox.example.comSafe to create/delete real-looking data
staginghttps://api-staging.example.comShared pre-production environment
productionhttps://api.example.comLive system — use with care
Running against staging with the “Happy path” case from the CLI:
reqflo run payments/checkout --env staging --case "Happy path"
Overriding a single value on top of a case:
reqflo run payments/checkout --env staging --case "Happy path" --set customer_id=cust_99

Environments concept

How environments work across Reqflo.

Cases

Named value configurations — separate from environments.

Service environments (admin)

Create and manage environments for your organization.

Value resolution order

How Reqflo resolves value conflicts between sources.