Helix Foundry: Local-First Data Workbench Unifies SaaS Data with On-Device AI

Problem: Fragmented Company Data

Customer data lives in Postgres, payments in Stripe, login events in WorkOS, behavioral events in PostHog, and CSVs from support. Answering a simple question — "Which customers subscribed last month but never opened the product?" — requires opening four backends, exporting four tables, and manually joining on customer ID in Excel.

Solution: Helix Foundry Local Data Workbench

Helix Foundry is a local-first data workbench built on two databases: HelixDB (metadata, ontology objects, and relationships) and DuckDB (analytical queries). It ingests from databases (Neon, Supabase, PlanetScale, PostgreSQL, MySQL), SaaS (Stripe, WorkOS, PostHog), REST APIs, S3-compatible storage, and file uploads (CSV, JSON, JSONL, Parquet), then automatically suggests a cross-source ontology that you can confirm or modify.

Core Components

Connectors : Native change capture for Postgres/MySQL; scheduled snapshots for other sources.

Ontology : Auto-suggested object types (Customer, Order, etc.) and relationships stored as real objects and edges in HelixDB.

Versioned Data : Immutable Parquet snapshots with profiles, key candidates, sensitivity hints, schema-drift review, and history.

Home & Analyst : Key-metric dashboards and Q&A backed by actual executed SQL with snapshot references.

AI Choice : Default local qwen3:4b via Ollama; optional Claude or OpenAI. AI proposals are tested and require human review before applying.

Developer Interface : OpenAPI at /api/docs, TypeScript SDK, workspace-scoped API tokens (read-only by default), backup/restore scripts.

Architecture: Five Docker Compose Services

App : React UI + API bound only to 127.0.0.1; handles tokens, publishing, actions.

Worker : Runs persistent AI tasks, scheduled imports, pipeline execution, proactive proposal generation.

Executor : Ephemeral DuckDB subprocess; loads only declared inputs; runs isolated SELECT statements.

HelixDB : Stores workspace metadata, API tokens, tasks, proposals, ontology objects and edges.

Ollama : Local structured inference; model weights persisted.

Data lives in three Docker volumes: helix-data (HelixDB metadata, encrypted credentials), foundry-data (Parquet snapshots, uploaded files), model-data (Ollama weights, not backed up). Only the App publishes a port, strictly on 127.0.0.1. The Executor runs in an internal network with no external access.

How Data Alignment Works

Unlike traditional BI tools that require predefined schemas and joins, Helix Foundry ingests data first, then suggests an ontology by matching cross-source customer identifiers and records. The suggested ontology — object types and relationships — is stored as real objects in HelixDB, not as a config file.

Versioning and review mechanisms ensure reliability:

Each import creates an immutable Parquet snapshot with profile, key candidates, sensitivity hints.

Schema changes trigger a drift review; old data is not overwritten.

AI-generated pipeline SQL, ontology mappings, and metrics run in preview first, with evidence and query preview.

Proposals have stale detection; publishing is atomic.

Both DAG-based pipelines (node graph compiled to SQL) and editable SQL are supported, with before/after diffs.

Security Model: Designed for One Person, One Machine

The project explicitly states it is for a single user on their own computer — no accounts, no login. Anyone with access controls all workspaces. Security focuses on keeping data on-device:

API only on 127.0.0.1; never behind reverse proxy, tunnel, or port forwarding. Internal ports (HelixDB, Executor, Ollama) must not be exposed.

Requests with non-local Host headers are rejected (DNS rebinding protection). Browser-initiated changes must originate from configured origin, else 403.

Connector and AI credentials encrypted with ENCRYPTION_KEY via AES-256-GCM. Losing the key makes credentials unrecoverable; key rotation is not supported.

Generated SQL runs in isolated DuckDB executor: network isolation, no connector credentials, dropped Linux capabilities, memory and process limits.

Scripts and SDK use workspace-scoped tokens from Settings → Developer Tools, default read-only.

Installation & First Run

Prerequisites: Docker with Compose v2, git, bash, openssl. First run downloads ~3.4 GB (app image ~0.9 GB + HelixDB + Ollama + qwen3:4b ~2.5 GB). Recommended memory: 16 GB.

Easiest path : Let your coding agent install. The repo includes AGENTS.md with a prompt for Claude Code, Codex, or Cursor:

Set up Helix Foundry on this computer.  Clone https://github.com/helixdb/helix-foundry.git (or use the copy I already have), cd into it, then read AGENTS.md and follow it to install, start and verify the app. Ask me before doing anything that deletes data or stops something that is already running. When it is ready, give me the URL and tell me what to do next.

The agent checks Docker, finds a free port, generates an encryption key in .env via scripts/setup.sh, builds and starts the stack, waits for health checks, and returns the URL. It never sees your Claude/OpenAI keys or database passwords — you enter those in the browser.

Manual install :

git clone https://github.com/helixdb/helix-foundry.git
cd helix-foundry
./scripts/setup.sh --compose

Ready when curl -fsS http://localhost:3001/api/health returns {"ok":true,"service":"helix-foundry"}. Open http://localhost:3001 — no registration. Onboarding walks through AI → Data → Ontology: choose local/Claude/OpenAI, connect data (or use sample data), confirm suggested ontology. Then view Home dashboards and ask questions in the Analyst box.

Common pitfall : If port 3001 is occupied, you must change both the port and the allowed origin together; changing only the port causes 403 Origin is not allowed on every save.

Apple Silicon optimization : Docker cannot use Metal. Install native Ollama, set MODEL_ENDPOINT to it, and start without --profile local for faster inference.

Performance Benchmarks (M1 Pro / 16 GB)

The project publishes honest benchmarks with clear scope limitations:

NDJSON → Parquet, 1 million rows: 472 ms

Concurrent analytical HTTP clients: 25

Executor slots: 2

Median response time including queue: 1690 ms

Slowest response including queue: 3139 ms

Crucially, these numbers exclude inference ; they measure executor load only, not 25 browser sessions. The 149 MB RSS reported is for the load-test client alone, not the whole platform. The project explicitly warns against misusing these figures.

Known Limitations (Explicitly Documented)

Local AI full reference workflow validated: given sample data and a "customer revenue + delayed orders" goal, the local model generated 3 catalog entries, 1 SQL pipeline, Customer and Order ontology types, 1 relationship, 2 dashboard widgets — 10 validations passed in 6 model calls, ~14,516 tokens, ~153 seconds.

Claude/OpenAI real-time calls not validated (no credentials available at test time; only protocol fixtures run).

16 GB peak memory certification for full local inference not yet done; million-row benchmark does not guarantee million-object ontology publishing works.

Ontology graph displays only first 100 objects; records paginated at 50 rows. Metadata lists currently load entire segment then slice — large ontologies need storage-layer pagination (acknowledged limitation).

Who It's For / Not For

Good fit :

Individual developers or small teams with data scattered across a few SaaS and a database who want to stitch it together on their own machine.

Privacy-sensitive users unwilling to send company data to third-party SaaS — entire pipeline local, AI can be local.

Developers who want coding agents to provision data infrastructure — designed from day one with an agent-readable runbook ( AGENTS.md).

Bad fit :

Teams needing multi-user collaboration, RBAC, or long-running online services — explicitly "one computer, one person", no account system.

Users who just want a BI dashboard — heavier (Docker + several GB images) for ontology + review + AI Q&A.

Windows users — developed/validated on macOS Apple Silicon, Linux CI; Windows untested , scripts depend on bash.

Learning curve: Medium . Installation via agent or a few commands, but requires Docker, memory, several GB disk, and initial model download. License: Apache 2.0.

Why It Matters: Local-First + Agent-Friendly Trend

Helix Foundry's design choices point to a clear direction: data tools are moving from "cloud SaaS" to "local-first + agent-friendly." The entire chain — installation ( AGENTS.md runbook), interaction (local AI + human review), security (loopback binding + credential encryption + executor isolation) — is built around "one person on their own computer, letting AI help organize their data," not around "how to scale a multi-tenant SaaS." This positioning defines its ceiling (no team collaboration) and its floor (maximum privacy and control). Whether it's worth adopting depends entirely on whether you accept that premise.

Project: https://github.com/HelixDB/helix-foundry (760+ stars, TypeScript, Apache-2.0, updated 2026-10-10)