Model or dataset
helicalinsight/helicalinsight avatar
helicalinsight/helicalinsight

Helical Insight 7.0.0: An AGPL BI Platform That Puts Paginated Reporting, Dashboards and BYO-LLM Chat in One Deployment

Free, open source BI platform with AI conversational analytics (BYO-LLM), pixel-perfect paginated reports, interactive dashboards, SSO, embedding, multi-tenancy & row-level security. Every feature free in Community Edition. Self-hosted, Docker-ready

963 stars662 forksJavaScriptAGPL-3.0

At a glance

What is it?
Helical Insight bundles conversational analytics, pixel-perfect paginated reports, dashboards, embedding and row-level security into a single self-hosted Java application under AGPL-3.0. The pitch is that every enterprise feature is free in the Community Edition; the trade-off is that you inherit a large Java stack and a copyleft licence rather than a single-purpose tool.
Who is it for?
Adopt Helical Insight if you need paginated, print-ready reports and embedded dashboards behind SSO and row-level security in one self-hosted deployment, and if AGPL-3.0 is acceptable for your distribution model. Do not adopt it if you only want ad hoc charting for internal analysts, or if you cannot run a Java stack.
Can I use it commercially?
Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap Helical Insight targets: reporting and dashboards that usually live in two products

Most open source BI deployments end up split in two. A dashboard tool handles exploration and charts. A separate reporting engine, often JasperReports, BIRT or Pentaho, handles the paginated documents that finance, operations and regulators actually sign off on: invoices, MIS packs, statements, statutory filings. The two halves have different security models, different schedulers and different embedding stories, and someone has to keep them in sync.

Helical Insight's stated position is that it covers both halves from one deployment. The README lists paginated pixel perfect reporting, interactive dashboards with drill-down and drill-through, AI chat analytics, embedding, white labelling, multi-tenancy and row-level security as features of the same product. The comparison material in the repository frames this against two groups: modern open source BI tools (Superset, Metabase, Redash, Lightdash) and reporting-first tools (JasperReports, BIRT, Pentaho, Crystal Reports).

The audience is therefore not an analyst who wants to chart a CSV. It is a team building an embedded analytics layer for a SaaS product or an internal portal, where end users log in through the host application's identity provider, see only their own rows, and occasionally need a PDF that paginates correctly. The repository also lists agentic-bi and ai-analytics among its topics, so the AI chat is presented as a first-class surface rather than an add-on.

How the pieces fit: a Java core, a JavaScript front end, and connectors you can extend

The repository's primary language is listed as JavaScript, but the README describes extension points in Java, JavaScript, CSS, HTML and Liquid Template Language, and the build workflow referenced in the badges is Maven. That combination points to a Java server with a browser-based designer and viewer, which is consistent with the deployment targets listed: Windows, Linux, Docker, Kubernetes, cloud, on-premises or hybrid.

Data access is the part with the most concrete detail. The README states that Helical Insight connects through native connectors, JDBC, REST APIs and custom integrations, and that users can upload custom JDBC drivers and start using them immediately. The supported source table spans four groups: big data and analytics engines (Athena, Redshift, Drill, ClickHouse, BigQuery, Hive, Presto, Trino, Snowflake, Teradata), flat files and cloud storage (CSV, Excel, JSON, Parquet, TSV, S3, Azure Blob, Google Cloud Storage, Cloudflare R2, Google Sheets), relational databases (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, DB2, SAP HANA, SQLite, Microsoft Access), and a mixed advanced group including DynamoDB, CockroachDB, DuckDB, Elasticsearch, YugabyteDB, Databricks, Dremio, Firebird, Informix and a generic API entry.

On the AI side, the mechanism described is bring your own LLM. The README says the chat generates SQL automatically, summarizes reports and surfaces insights, with agentic capabilities. What it does not state in the material available here is which model providers are supported out of the box, where the model endpoint is configured, or what data leaves the deployment during a chat turn. That is a gap worth noting rather than glossing over, because it determines whether the feature is usable in a regulated environment.

Security is described at the data level rather than only at the application level: row-wise, column-wise and table-wise restrictions resolved from the logged-in user context. Multi-tenancy is described as data isolation for multiple customers or departments from a single deployment. Both claims are structural, and both depend on how your own authentication payload maps onto those rules.

Getting it running: Docker is the documented path

The README points installation at the project's Docker installation page rather than reproducing commands inline, so the exact image tag and environment variables are not in the material I have. What the repository does establish is that a Docker image is published under the Docker Hub namespace hiee, referenced by the Docker Pulls badge, and that the homepage links a dedicated Docker installation guide plus a Getting Started guide.

The practical sequence the documentation implies is: pull the image, start the container, open the application in a browser, and complete first-run setup. Beyond that, the configuration surface named in the README is functional rather than file-level. You configure data sources by selecting a connector or uploading a JDBC driver. You configure identity through JWT, Okta, Keycloak, OAuth or a custom token, with a linked SSO guide. You configure branding through white labelling of logos, themes, colours and URLs. You configure delivery through the scheduling and report bursting feature, which sends reports and dashboards by email.

I cannot give you verified config keys, port numbers, volume mounts or environment variable names, because none appear in the supplied README. Anyone evaluating this should treat the Docker installation page and the Getting Started page as the authoritative setup references and budget time for them, rather than expecting a single docker run line to be sufficient for a multi-tenant deployment.

For developers, the README names the extension mechanisms explicitly: Java, JavaScript, CSS, HTML, Liquid templates, REST APIs, plugins and custom workflows referred to as HWF. The REST API documentation is linked separately. That is a real integration surface, but it is also a sign that deep customisation means writing code against a platform-specific model.

Where the design costs you: breadth, licence and the AI black box

The first limitation is scope itself. A platform that does dashboards, paginated reporting, scheduling, embedding, multi-tenancy, localization, white labelling and AI chat is a large surface to operate. Every one of those subsystems has its own configuration, and the README describes them at marketing depth rather than operational depth. There is no sizing guidance in the material, no statement about minimum memory for a given number of concurrent users, and no description of how caching, pagination, virtualization, load balancing and clustering interact when you scale out. Those terms appear in the feature table as a list, not as an architecture.

The second is the licence. AGPL-3.0 is a strong copyleft licence with a network clause. If you embed Helical Insight into a hosted service and modify it, the AGPL's source-availability obligation can extend to users interacting with it over a network. The README markets embedding for SaaS platforms and customer portals, which is exactly the scenario where that clause deserves a lawyer's attention before you build on it. Nothing here is legal advice, and the repository does not include a licensing FAQ explaining the project's own position on embedding.

The third is the AI feature. Bring your own LLM is a sensible design for cost and data control, but the README does not say how schema information is passed to the model, whether generated SQL is shown to the user before execution, or what guardrails exist against a prompt that produces a destructive or expensive query. Automatic SQL generation against a production warehouse is a feature that needs those answers documented, and in the material supplied they are not.

Finally, the feature table claims every enterprise feature is free in the Community Edition, while the product is also sold commercially. The README does not explain what the paid editions add. That absence is not proof of a problem, but it is the first question to resolve with the vendor.

How it differs from Metabase and Superset, and from JasperReports

Against Metabase, the difference is the reporting model. Metabase is built around questions, saved explorations and dashboards, and its output is a screen-first artifact. Helical Insight treats paginated, printer-friendly reports as a peer of dashboards, aimed at invoices, MIS reports, financial statements and regulatory filings. If your users never print or export a fixed-layout document, that half of the product is weight you carry without using.

Against Superset, the difference is the intended consumer. Superset is a SQL-first exploration tool for people comfortable with a semantic layer and chart configuration. Helical Insight presents itself as embeddable infrastructure: SSO, row-level security, multi-tenancy and white labelling are listed as core features rather than enterprise add-ons. The repository explicitly targets OEM and embedded deployments. That also means the comparison is not purely technical. Superset is Apache-2.0, which is permissive; Helical Insight is AGPL-3.0. For a product you redistribute, that single line changes the engineering decision more than any feature table.

Against JasperReports and BIRT, the difference runs the other way. Those are reporting engines with long histories and large template ecosystems. Helical Insight adds dashboards, AI chat and modern embedding around its reporting capability. If your reporting needs are already met by an existing JasperReports estate, migrating templates is a cost the README does not address, and the comparison material in the repository covers capability categories rather than migration paths.

What maintenance and upgrades look like from the repository

The repository shows an active project rather than an archived one: the default branch is master, the last push date is 2026-09-09, and the most recent release listed is v7.0.0 from 2026-07-30. A Maven build workflow runs against master, and the README links a forum, usage videos and a support email address. Those are the maintenance channels the project itself advertises.

What the material does not provide is an upgrade guide, a version support policy, or a statement about database schema migrations between major versions. A 7.0.0 release implies prior major versions, but the supplied release list contains only that one entry, so I cannot say how frequently majors ship or how disruptive they are. For a platform that stores report definitions, dashboards, schedules and tenant configuration, the upgrade path matters more than the release cadence, and it is not documented here.

The practical maintenance cost is the stack. You are running a Java application with a JavaScript front end, a metadata database, connections to every source you register, a scheduler that sends email, and an integration with an external LLM endpoint if you enable chat. Each of those is a thing that can fail independently, and the README describes clustering and load balancing as supported without describing the coordination model. Teams without Java operational experience should weigh that honestly.

On licence maintenance, AGPL-3.0 means the source of your modifications may need to be available to network users. If your deployment is internal-only and unmodified, the obligation is lighter than in a redistributed SaaS product. Either way, the licence file governs, and the repository's own framing of embedding for SaaS is the scenario to review first.

Editorial conclusion

Adopt Helical Insight if you need paginated, print-ready reports and embedded dashboards behind SSO and row-level security in one self-hosted deployment, and if AGPL-3.0 is acceptable for your distribution model. Do not adopt it if you only want ad hoc charting for internal analysts, or if you cannot run a Java stack. Before committing, verify two things against your own environment: that your database has a working connector or that your custom JDBC driver loads, and that the BYO-LLM chat path talks to your model endpoint without sending query results anywhere you have not approved.

Official sources

  1. helicalinsight/helicalinsight on GitHub
  2. License: AGPL-3.0
  3. Project website
  4. README
  5. Releases
Community notes

Community notes