Enso

Enso is a self-service data preparation and analysis platform aimed at data teams in finance, accounting, and revenue operations who need repeatable pipelines without writing (or being locked out of) code. What sets it apart architecturally is that its visual node-graph editor and its textual Enso language are two renderings of the exact same parsed AST rather than a one-way canvas-to-code export: a shared Rust parser compiles to WebAssembly for the desktop GUI and to a native JNI library for the JVM engine, with generated Java bindings keeping both sides in lockstep. Editing a node updates the source, and editing the source updates the graph.

Under the hood, the Enso Engine is a Scala/Java codebase running on GraalVM, using a Truffle-based interpreter and JIT compiler so that live edits to a pipeline re-execute with near-native interactive speed instead of a full batch re-run. The standard library (distribution/lib/Standard/, backed by std-bits/ Java helpers) ships built-in connectors for Snowflake, DuckDB, AWS, Google Cloud, Microsoft, and Tableau, so workflows can pull from and land in real data platforms rather than staying local-only.

The desktop IDE is an Electron application built from a pnpm/TypeScript monorepo, mixing a Vue 3 graph editor (the direction the project is moving) with a still-present React-based dashboard for project and cloud account management. A ydoc-server layer backs real-time multiplayer editing for Enso Cloud, which is metered by Free/Solo/Team/Enterprise plans.

Licensing is split rather than singular: the Enso Engine (interpreter, compiler, language server, CLI) is Apache-2.0, the IDE (app/gui) is AGPL-3.0, and the pre-built downloadable binaries are covered by a separate commercial EULA (with no-cost licenses available to individuals and small companies) — so “self-hosted and free” and “open source” aren’t quite the same claim here.

What You Get

• A dual visual/textual editor where node-graph and source-code views are always in sync, backed by one shared Rust-parsed AST
• A GraalVM Truffle-based interpreter and JIT for the Enso language, giving interactive re-execution speed as pipelines are edited live
• Built-in data connectors (std-bits/) for Snowflake, DuckDB, AWS, Google Cloud, Microsoft, and Tableau
• A cross-platform Electron desktop IDE for Windows, macOS, and Linux
• An extensible standard library (distribution/lib/Standard/) covering table, database, image, and cloud-storage operations
• A language server (engine/language-server) exposing evaluation, inspection, and suggestions over a polyglot protocol
• Optional Enso Cloud for real-time multiplayer project collaboration and scheduled/serverless execution

Common Use Cases

• Finance teams automating budget-to-actuals reporting by blending exports from multiple ERP systems into one repeatable workflow
• Accounting teams reconciling transactions across systems to close the books faster and more consistently
• Revenue operations analysts combining CRM and marketing-automation data to calculate sales commissions without hand-written SQL
• Tax teams blending data from multiple entities and source systems into a single normalized reporting pipeline
• Data analysts prototyping transformations visually, then switching to the underlying Enso code for edge cases the canvas can’t express

Under The Hood

Architecture Enso is genuinely two products sharing one monorepo: the Enso Engine (engine/) implements the language itself — parser, compiler passes (PassManager, BindingsMap, CompilerConfig under engine/runtime-compiler), a GraalVM Truffle interpreter, and a language server (engine/language-server) that exposes the running program over a polyglot API — while the Enso IDE (app/gui) is an Electron desktop app pairing a Vue-based visual graph editor with a legacy React dashboard still being migrated to Vue. The two halves are glued by a Rust parser (lib/rust/parser) that acts as the single source of truth for the AST: it compiles to WebAssembly for the GUI and to a JNI native library for the JVM engine, with its types code-generated into Java so both sides deserialize the exact same tree — meaning the node graph and the textual source are literally two views onto one parse result rather than a one-way export. Real-time collaboration between GUI and engine runs through a dedicated ydoc-server layer. Changing the core AST cascades through the parser, the generated Java bindings, and the WASM bundle simultaneously, which is both the project’s central architectural fragility and its central design commitment.

Tech Stack The interpreter and standard library are Scala/Java on GraalVM, built with a large sbt project and JPMS-friendly wrappers in lib/java for third-party integrations — gRPC, SQLite, Akka, Apache POI, OpenCV, DuckDB. Data connectivity lives in std-bits/, with dedicated modules for AWS, Google, Microsoft, Snowflake, DuckDB, and Tableau. The parser, CLI build orchestrator, and installer tooling form a pinned-toolchain Rust workspace targeting both native and wasm32. The desktop IDE is a pnpm-managed TypeScript monorepo built with Vite/esbuild, mixing Vue 3 (the primary UI framework going forward) with a still-present React dashboard, Zustand for state, Zod for schema validation, AG Grid Enterprise for tables, and AWS Amplify plus Stripe-based billing components for the Cloud product. Bazel is being rolled out as the unifying build graph across these historically separate build systems (Cargo, pnpm, sbt, and a legacy Rust CLI orchestrator).

Code Quality The engine carries extensive ScalaTest-style integration suites across dozens of test directories, exercising compiler passes end-to-end against real Enso source, and the Rust parser embeds its own unit tests plus a dedicated fuzzing crate. The GUI layer uses Vitest for unit tests and Playwright-driven integration specs that exercise the graph editor directly — component browser, node coloring, AI-assisted nodes, table visualization. Formatting and linting are enforced comprehensively: rustfmt/clippy for Rust, scalafmt for Scala, and ESLint/Prettier with strict TypeScript for the frontend. CI is unusually mature for an open-source project, running on self-hosted runners with a Bazel remote cache and separate nightly pipelines for engine, GUI, and IDE packaging across desktop platforms.

What Makes It Unique Most low-code data tools generate code as a one-way export from a canvas; Enso inverts that by making the visual graph and the textual language two renderings of the same parsed AST, kept isomorphic by sharing one Rust parser compiled to both WASM and a JVM-native library. Paired with a GraalVM Truffle-based JIT, edits in either view re-execute the affected part of the pipeline with near-native interactive speed rather than a full batch re-run — a genuinely distinct technical bet compared to workflow-canvas tools like the ones it’s positioned against commercially.

Self-Hosting

Licensing Model Licensing is split by component: the Enso Engine (interpreter, compiler, language server, CLI tools) is Apache-2.0, and the Enso IDE (app/gui) is AGPL-3.0. Downloadable pre-built binaries are not open source and are covered by a separate EULA, though no-cost licenses are offered to individuals and small companies.

Self-Hosting Restrictions

• Building the Engine and IDE from source under their respective open-source licenses carries no functional restrictions found in this codebase.
• Enso Cloud features (multiplayer collaboration, hosted scheduling, account/billing infrastructure) are separate from the self-built engine/IDE and are not something self-hosting replicates.

Enterprise Features Sourced from the dashboard’s own paywall configuration (app/gui/src/composables/paywall/FeaturesConfiguration.ts):

• Uploading projects to Enso Cloud requires at least the Solo plan
• Inviting additional users is capped at 10 seats on the Team plan; unlimited invites require Enterprise
• User groups are capped at 1 group on the Team plan; unlimited groups require Enterprise
• Sharing projects is available on the Team plan; full sharing requires Enterprise
• The workflow scheduler requires the Team plan or above
• The Enterprise tier is sold via “Contact Sales” rather than self-serve checkout

Cloud vs Self-Hosted These plan gates are enforced by Enso Cloud’s account/billing system, not by the open-source Engine or IDE source code itself. Self-hosting from source bypasses Cloud billing entirely but also does not include Cloud’s hosted multiplayer collaboration, scheduler, or account/plan infrastructure.

License Key Required No. Open-source Engine/IDE builds from source require no license key. Enso Cloud enforces feature gates by account plan rather than a local license key, and downloadable pre-built binaries are governed by the ensoanalytics.com EULA instead of a key.