Why Ciaren Exists

Every team that works with data eventually faces the same fork in the road.

Down one path are the visual tools — KNIME, Alteryx, and their cousins. They're genuinely fast to start with: drag nodes, connect them, see results. But the workflow you build lives inside their runtime. The logic is real, the understanding is real, and yet none of it survives outside the tool. When you outgrow it — or the license does — you rewrite everything.

Down the other path is code-first orchestration — Airflow, Dagster, Prefect, or plain Python scripts. Full ownership, full power, and a very different bill: every pipeline starts at a blank editor, every iteration is a rerun, and everyone who touches it must be comfortable writing and reviewing code. For a warehouse-scale platform team, that's the right call. For "join these two files, clean them, train a quick model," it's a lot of ceremony.

Ciaren exists because that trade-off is artificial.

The premise

A visual pipeline is a graph of well-understood operations: read, filter, join, aggregate, train, write. There is no technical reason a tool can't let you build that graph visually and then hand you the equivalent Python — real pandas or Polars code, the same code you'd have written by hand.

So that's what Ciaren does:

• Build visually. Drag nodes onto a canvas — 80 built-in nodes covering transformations, SQL and file inputs, cloud storage, data-quality checks, charts, ML training.
• Preview on real data. Click any node and inspect the actual rows it produces before running anything downstream.
• Export honest code. One click generates a standalone pandas, Polars, or lazy-Polars script. No SDK import, no proprietary runtime, no phone-home. Delete Ciaren and the script still runs.

The exported code is the escape hatch that changes the relationship with the tool. You're never locked in, so the tool has to keep earning its place — which is exactly the incentive an open-source project should have.

Local-first, deliberately

Ciaren runs on your machine. One pip install, one command, and the editor, the engine, and your data are all local. No account, no upload, no "your data was processed in region X" surprises. That's not a limitation of this early stage — it's the design. Most data work happens on files and databases you already have access to; a tool shouldn't require sending them anywhere. (We wrote more about this in Why Local-first Matters.)

Open source, open core

The core is AGPL-3.0 and it's the complete product: both engines, all nodes, export, scheduling, ML with MLflow tracking, and the plugin SDK. The plugin API is Apache-2.0, so anyone can build and even sell extensions on top of it. If commercial editions ever ship, they'll add organizational controls — SSO, RBAC, private plugin registries — on top of the core, not carve features out of it.

What Ciaren is not

Honesty is cheaper than churn, so: Ciaren is not a real-time streaming engine, not a warehouse-scale orchestrator, and not a multi-tenant SaaS. If you're scheduling thousands of interdependent DAGs across a cluster, Airflow-class tools are the right home — and Ciaren will happily export the Python you migrate there. Ciaren's territory is the enormous middle ground: the ETL, cleaning, analytics, and lightweight ML work that today gets done in fragile notebooks or expensive licensed suites.

Where it stands

Ciaren is in early development — v0.1.0. APIs and formats will still move. But the end-to-end loop works today: build a flow, preview each step, run it on Polars or pandas, schedule it, and export code you actually own.

If that premise resonates, the repo is open, the docs are here, and the roadmap is public. Star it, break it, tell us what's missing.