continuoA control plane for dbt and Python projects with blue/green validation and agentic remediation.
Independent projects, one inferred graph. Every release is proven in a schema clone before it becomes production. A rejected release gets a proposed fix for a human to review.
kind create cluster --name continuo helm install continuo oci://ghcr.io/carolsimone/charts/continuo \ --version 0.4.0 -n continuo --create-namespace
Data pipelines ship without a release process. A model changes, the nightly run is the first test, and production finds the bug.
Continuo gives data a release process.
Every release goes through the same gate.
Publish an image
Your CD builds the project image, as it does today.
POST /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.
Two-minute walkthrough. Coming soon.
Less to write. Less to break.
- 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 teams that share tables.
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 the platform and, with your confirmation, acts on it.