Status and roadmap
AutoFlow is in early access for GitLab teams: a workflow starts through the AutoFlow gRPC API, and there is no beta or GA label yet. The planned end state is an AutoFlow-only Relay deployed on Theseus, first for GitLab.com and later for self-managed Kubernetes.
Available today
| Area | Status | Notes |
|---|---|---|
gRPC API: StartWorkflow, GetWorkflow, CancelWorkflow, SendToWorkflowChannel | Available | Polling GetWorkflow is the only way to observe progress; there is no callback or stream. |
Starlark surface: main(w, ...), gather, select, channel, sleep, timer, poll, derived_action, struct, module, time, json, math | Available | See Starlark. |
Durable timers, channels, poll, child workflows | Available | A waiting workflow holds no resources. |
gitlab module: call_api, post_value | Available | Calls the GitLab REST API; authentication comes from the headers the workflow passes. |
policy module: evaluate | Partial | Returns ALLOW until a policy source is wired, and needs an AutoFlow build that includes the policy engine. |
event module: emit | Partial | Publishes CloudEvents; loads only when Relay’s events platform is enabled. |
gitlab-function module: run | Available | The deployment functions module (builtin:// functions); its GitLab token comes from AutoFlow’s environment. |
autoflow CLI: run, get, cancel | Available | Submits a workflow definition to a running AutoFlow instance and waits for the result. Also available as kas autoflow in every kas binary, the relay image included. |
| Local try-out via Caproni | Available | fragments/caproni.autoflow.yaml deploys AutoFlow next to GitLab on the Caproni rig, with scripts/autoflow.sh to run a workflow; see Get started. Added in gitlab-caproni!122. |
| Limits | 100 KiB per workflow definition, 30 days lifetime by default and 60 at most, 10,000 channel values per workflow. See Limits. |
In design
| Area | Status | Notes |
|---|---|---|
| A new shape for the Workflow and Execution APIs | Planned | Proposed in ADR 0011; the current RPCs, messages and tokens are subject to change. |
| Third-party remote modules | Partial | The protocol exists on the AutoFlow side: ModuleAPI and ModuleTunnelAPI are gRPC and protobuf, so a module can be written in any language, and the Go SDK in pkg/autoflow implements them. Credential issuance for module agents does not exist yet, so new capabilities ship compiled in, built with the SDK. |
| Log streaming and a UI | Planned | print output goes to AutoFlow’s log; there is no user-facing stream or workflow view. |
| AutoFlow-only Relay on Theseus and Runway | Partial | One kas process with only the AutoFlow module, deployed from a chart: running on the caproni rig, then Runway staging, production on GitLab.com and self-managed Kubernetes. |
One constraint from the Theseus epic: Theseus reaches self-managed customers only through Kubernetes, so a Linux package installation without a cluster gets no AutoFlow through this path. Relay stays where it is today for its other modules.
Where it runs today
AutoFlow keeps workflow state in PostgreSQL 17 (one central database plus one or more workflow databases, no extensions, no superuser) and coordinates its instances through Redis. A workflow starts only through the gRPC API, called by GitLab features and by the autoflow command line tool. Workflow data is retained for 90 days.