Skip to main content

Overview

Workflow Service​

Sedaro's Workflow Service lets you run multi-step simulation pipelines on our hardened infrastructure — reliably, repeatably, and at scale. It is built to solve a common problem in simulation and data engineering: running complex, multi-step processes at scale that depend on specific code versions, need configurable inputs, and that must produce traceable, reproducible outputs.

Instead of manually orchestrating scripts or managing container execution yourself, the Workflow Service handles:

  • Scheduling and execution of containerized steps on our scalable runtime
  • Dependency management between steps, passing outputs from one to the next
  • Version control integration, so your workflows are deterministic and always tied to a specific Git state
  • Runtime source code delivery, so workflows can automatically fetch and clone the exact code they need — from external repositories — directly into the execution environment at runtime, without baking it into a container image
  • Runtime configuration, so the same workflow can be run with different inputs without editing any code
  • Execution history, giving you an immutable record of every run with logs and outputs

Key Constructs​

There are four core constructs in the Workflow Service:

Workflow Definition Template​

A Workflow Definition Template is the workflow.yaml file that lives in a Git repository. It is the blueprint — it defines the steps, container images, resource requirements, dependencies, and configurable parameters that make up a workflow. This file is authored and maintained by the workflow developer.

Workflow Definition​

A Workflow Definition is a pointer to a Workflow Definition Template. It is automatically created by the system when the background scanner discovers and validates a workflow.yaml file in a connected Git repository. You don't create definitions manually — you simply browse the ones already available in your project. Think of it as the system's registered reference to the blueprint.

Workflow Instance​

A Workflow Instance is a reusable configuration that links to a Workflow Definition and pins it to a specific Git reference (i.e., ref) — a branch, tag, or commit SHA.

  • A branch-based instance (e.g., main) always tracks the latest commit on that branch
  • A tag or SHA-based instance (e.g., v1.2.0) is permanently pinned to that version

Think of an instance as a saved template you can execute many times with different inputs.

Workflow Run​

A Workflow Run is a single execution of an instance. When you create a run, the service locks it to the exact commit SHA at that moment, applies any runtime configuration you provide, and executes the pipeline. Runs are immutable records — you can always go back and see exactly what ran, who ran it, with what inputs, and what it produced.

Lifecycle of a Workflow​

At its core, the Workflow Service connects three things: your code in Git, your configuration, and scalable runtime infrastructure. A Workflow Definition Template — the workflow.yaml in your Git repository — is the blueprint that describes what should run. The system automatically discovers this blueprint and registers it as a Workflow Definition in your project, keeping it in sync as your Git repository evolves.

From there, you create a Workflow Instance that binds the definition to a specific Git reference — a branch, tag, or commit SHA — representing the version of the workflow you want to use. The instance is your reusable, named configuration that you can execute as many times as you need with different inputs.

Each time you execute an instance, a Workflow Run is created. The run locks to the exact code state at that moment, pulls in any required source dependencies, applies your runtime configuration, and executes the pipeline. The result is an immutable record of exactly what ran, with what inputs, and what it produced.