Why Local-first Matters for Data Pipelines

Most modern data tools begin with a signup form. Before you've loaded a single CSV, you've created an account, agreed to terms, and — often without noticing — accepted that your data will be processed on someone else's computers.

For plenty of workloads that's fine. For many others it's a non-starter:

Regulated data. Health records, financial transactions, HR data. Legal review of a new cloud subprocessor can take longer than the project itself.
Client data. Consultants and agencies often can't upload a client's dataset to a third party at all, contractually.
Just-not-your-business data. The spreadsheet of salaries, the churn list, the experiment that isn't ready to exist outside one laptop.

The usual answer is "self-host our platform," which trades the privacy problem for an infrastructure one: a Kubernetes cluster, a services mesh, and a part-time job keeping it alive — to clean a CSV.

What local-first means in Ciaren

Local-first is a simple contract: the tool comes to the data, not the other way around.

Concretely, in Ciaren:

pip install ciaren, run one command, and everything — the visual editor, the API, the execution engine, run history — lives in a local process with a local SQLite file. No account, no callback to anyone's cloud.
Your files are read from your disk. Your SQL queries run against databases you already have credentials for. Remote object storage (S3, Azure Blob, GCS) is supported, but as an explicit connection you configure, never a default.
Credentials go to your OS keychain, environment variables, or secret files — never into the app database.
Runs, previews, trained models, and MLflow experiments are all files and processes on your machine. Turn off Wi-Fi and Ciaren keeps working.

Ciaren connections page showing the built-in local MLflow tracking and local folder storage connections, with a note that secrets are read from environment variables, never stored

Local-first also quietly fixes the performance story for a whole class of work: there is no upload step, no per-row ingest pricing, no waiting on a shared cluster. A Polars engine on a modern laptop chews through millions of rows faster than most teams' staging environments.

Local-first is not anti-cloud

This isn't a purity position. Data lives in Postgres, Snowflake, S3 — Ciaren connects to all of them. Exported pipelines are plain Python precisely so you can run them in a cloud job, a container, or a CI pipeline. And a hosted edition may exist someday for teams that want it.

The distinction is defaults and direction: cloud should be an option you reach for, not a precondition for opening the editor. A tool that requires your data as a hostage to be useful has its incentives backwards.

The trust dividend

There's a subtler benefit. Because Ciaren runs where you can see it — open source, local process, inspectable database, exportable code — trust doesn't depend on a compliance page. You can read what it does. For a tool that sits between raw data and business decisions, that's not a nice-to-have; it's the foundation everything else stands on.

Local-first, open source, and code export aren't three separate features. They're one idea stated three ways: your pipelines belong to you.

Try it: github.com/ciaren-labs/ciaren — or see what you can build with it.