Skip to main content
When you run a journey, Reqflo doesn’t execute the live definition directly — it first compiles the journey into a build artifact. The artifact is a resolved, self-contained execution plan: steps, value references, assertions, and all. It’s what the runner actually executes, and it’s what makes cloud runs repeatable and debuggable.

​
When to use it

You don’t trigger this process manually — Reqflo handles it automatically when a run starts. But understanding the artifact model is useful when you need to:
  • Understand why a run reflects an older journey definition.
  • Debug a cloud run by inspecting what the runner received.
  • Think about repeatability: two runs from the same artifact will behave identically (given the same inputs and environment).

​
Key concepts

  • Journey version — a snapshot of the journey definition at a point in time. Versions are created as you iterate on the journey in Build mode.
  • Build artifact — the compiled output of a journey version. An artifact resolves the journey’s structure (steps, value references, assertions, execution plan) into a format the runner can execute. Artifacts are immutable: once created, they don’t change.
  • Compilation — the process of turning a journey definition into a build artifact. Reqflo performs this automatically when a run is initiated. Value sources are recorded; actual secret values and run inputs are not baked into the artifact.
  • Cloud Runner — executes artifacts with durable worker execution. Because the artifact is self-contained, the Cloud Runner can execute it reliably and re-run it if needed. See Cloud Runner for more.
  • Repeatability — two runs from the same artifact produce the same execution plan. Run inputs, environment values, and secrets are supplied fresh at run time, but the structure of what’s executed doesn’t change.

​
How it works

When you start a run:
  1. Reqflo takes the current (or specified) journey version.
  2. It compiles the journey into a build artifact — resolving step order, value source references, assertion definitions, and the execution plan.
  3. The artifact is handed to the runner (local CLI or Cloud Runner).
  4. The runner executes the artifact, resolving run inputs, environment values, and secrets at execution time.
Version tracking: The journey version associated with a run is recorded alongside the run results. If you go back to a completed run, you can see which version of the journey produced it. Artifact inspection: For cloud runs, the artifact is available for inspection. This is useful for debugging: you can confirm exactly what the runner received, independent of any changes made to the journey after the run.
Secret values and run inputs are not stored in the build artifact. The artifact records references to secrets and run inputs; actual values are resolved at execution time by the runner.

​
Examples

A typical flow:
  1. You update step 2 of checkout-flow to add a new assertion.
  2. You start a run. Reqflo compiles a new build artifact reflecting the updated step.
  3. The Cloud Runner executes the artifact. The run result records that it used checkout-flow version v14, artifact artifact_abc123.
  4. A colleague re-runs the same artifact for a different environment — the execution plan is identical; only the environment values differ.
From the CLI, triggering a cloud run: 
reqflo run payments/checkout --env production --case "Happy path" --cloud
Reqflo compiles the artifact and hands it to the Cloud Runner, which executes it durably.

Run artifacts concept

The mental model for build artifacts and their role in execution.

Cloud Runner

Durable cloud execution for journey artifacts.

Durable execution

How the Cloud Runner handles retries and failure recovery.

Details panel

View version info for the current journey.