continuoA control plane that runs your dbt and Python pipelines — with blue/green validation, agentic remediation, and an LLM chat.
Independent dbt and Python projects, stitched into one graph — the platform infers it, so you never wire it up. Every release is proven in a schema clone before it becomes production. When one is rejected, a remediation agent opens a pull request with the fix for a human to review. An LLM chat inspects and acts on your pipelines and schedules in plain language.
kind create cluster --name continuo helm install continuo oci://ghcr.io/carolsimone/charts/continuo \ --version 0.9.1 -n continuo --create-namespace
Every release goes through the same gate.
Publish an image
Your CD builds the project image, as it does today.
POST /api/v1/releases
continuo compiles the project and infers the graph. No DAG file.
Validate in a schema clone
The full downstream lineage runs on a copy. Other teams' models included.
Two minutes, end to end.
Install, POST a release, validation running, the graph, one rejection with its fix PR.
What a release process gives your data.
- No hand-written DAGs. Dependencies come from your SQL and Python contracts.
- One graph across projects. dbt and Python stitched together, edges crossing both ways.
- Blue/green for data. Every release runs in a schema clone against its full lineage.
- Production never runs a broken graph. A rejected release leaves the last good version live.
- Breakage lands on the author, even when the damage is in another team's model.
- Agentic remediation. A fixable rejection gets a diff and, with a GitHub App, a pull request.
Built for a data mesh.
Several teams, separate projects
Projects read each other's tables. A change should be checked across that boundary before it ships.
A fix before the deploy
An agent proposes the fix before the change is deployed, not after the nightly run fails.
Ask in plain language
An LLM chat in the UI inspects your pipelines and schedules and, with your confirmation, acts on them.