Skip to main content
Before a journey runs in the cloud, Reqflo compiles it into a build artifact: a resolved, self-contained package that captures the journey’s structure, steps, value references, assertions, and execution plan. The Cloud Runner executes this artifact, not the raw journey definition. This separation is what makes cloud runs repeatable, auditable, and debuggable.

​
When to use it

You don’t manually create or manage build artifacts — Reqflo handles compilation automatically when you trigger a cloud run. But understanding artifacts matters when you:
  • Need to know exactly what ran during a specific run (the artifact pins the state).
  • Are debugging a failure in a cloud run and want to verify what the runner saw.
  • Want to understand why re-running a journey might produce different results than a prior run (if the journey changed between runs, the artifact will differ).
  • Are building repeatable CI checks that must be stable across runs.

​
Key concepts

An artifact is a compiled snapshot, not the live journey. Once an artifact is built, it reflects the journey at a specific point in time. If you edit the journey afterward, future runs compile a new artifact. Past runs still reference the artifact that was current when they ran — you can always look back. Artifacts resolve the journey definition. The compilation step resolves references: step order, value source configuration, assertion definitions, and the execution plan. The artifact is explicit — nothing is left ambiguous for the runner to interpret. The Cloud Runner executes artifacts. When you run a journey with --cloud or trigger a run from the editor, the Cloud Runner picks up the artifact and executes it with durable worker execution. See Cloud Runner. Local runs via the CLI compile and execute similarly but do so locally. The same artifact concept applies; the runner is just running on your machine. Artifacts support repeatability and debugging. Because an artifact captures a fixed state, you can rerun the exact same artifact to verify whether an issue is in the journey definition or in the system under test. Run logs and evidence are tied to the artifact that produced them.

​
How it works

  1. You author a journey in Build mode.
  2. When you trigger a run (via the editor, CLI, or scheduled automation), Reqflo compiles the journey into a build artifact.
  3. The artifact is stored and handed to the Cloud Runner (or local executor).
  4. The runner executes the artifact step by step, resolving values at execution time (secrets, environment values, run inputs).
  5. Run results, logs, and evidence are linked to the artifact for future reference.
From the CLI, a cloud run compiles and executes automatically: 
reqflo run checkout-flow --cloud --env staging --case "Happy path"

​
Examples

Think of the relationship like source code and a compiled binary. The journey YAML is the source. The build artifact is the compiled output. The Cloud Runner executes the compiled output — it doesn’t re-interpret the YAML on every run. This means:
  • What ran is always knowable, even months later.
  • A broken journey edit doesn’t retroactively change what previous runs did.
  • You can pin a known-good artifact for scheduled or repeatable automation.