Skip to content

Architecture

AntFlow turns CWL workflows stored in GitLab into processes that users can run through a web interface or the OGC API - Processes interface. The server manages jobs; launchers execute them on the selected infrastructure.

Component model

AntFlow architecture

Runtime components

Component Responsibility
Server Discovers workflows from GitLab, exposes the process API, manages jobs, and tracks execution status and results.
UI Lets users browse processes, submit jobs, and inspect status, logs, and outputs through the Server API.
Launcher Fetches jobs and their CWL packages, runs workflows, publishes outputs, and reports status and results to the Server.

Connected services

  • GitLab hosts workflow repositories. Project access follows the user's permissions.
  • GitLab or Keycloak provides user authentication through OIDC. Launchers use separate registration tokens.
  • PostgreSQL stores the Server's application state.
  • S3-compatible storage holds published workflow outputs. Optional STAC cataloging makes results discoverable.

From workflow to results

  1. A workflow author stores a CWL package in GitLab. The Server makes accessible workflows available as processes.
  2. A user selects a process and submits inputs through the UI or API. The Server creates a job.
  3. A registered Launcher fetches a job matching its execution capabilities and runs the workflow on its backend.
  4. The Launcher reports progress and results to the Server. Outputs are published to object storage and can optionally be cataloged in STAC.

Execution backends

Each Launcher uses one backend. Multiple Launchers can connect to the same Server to serve different execution infrastructures.

Infrastructure Execution engine Guide
Kubernetes Calrissian schedules workflow steps as pods. Kubernetes launcher
A Linux host cwltool runs tools through Docker or rootless Podman. Local launcher
HPC with Slurm Toil schedules work through Slurm with Singularity containers. Toil / Slurm launcher

What's next