groundx-on-prem deploys a document RAG stack into your own cluster

Three services, one chart set

The repository is the infrastructure for the GroundX product, and the README describes the product as three interlocking systems. GroundX Ingest is a vision model trained on over 1M pages of enterprise documents, which analyses visually complex documents in a variety of formats, converts them into a queryable representation designed to be understood by LLMs, and stores that for downstream search. GroundX Store is the encrypted storage for source files, semantic objects and vectors. GroundX Search is built on OpenSearch and combines text and vector search with a fine-tuned re-ranker. The deployment itself has two key steps according to the README: optionally creating infrastructure on AWS with Terraform, then deploying GroundX onto Kubernetes with Helm. The repository layout matches that shape, with a helm/ directory, a helm-releases/ directory, a terraform/ directory, an ops/ directory, a monitoring/ directory, a src/ directory, plus sample.values.yaml and service.yaml as the configuration entry points.

The dependency set is the real design decision

The table of contents lists the services GroundX expects to find, and each one has a documented path for an existing cluster, a dedicated cluster, or a managed cloud equivalent. Redis can use an existing Redis cluster or be deployed as a dedicated one. MySQL has the same two options. MinIO can use an existing MinIO cluster, use AWS S3, or be deployed as a dedicated cluster. OpenSearch can use an existing cluster or a dedicated one. Kafka can use an existing Kafka cluster, use AWS SQS, or be deployed as a dedicated one. That last set of choices is the interesting part of the design, because replacing MinIO with S3 and Kafka with SQS turns a stateful multi-service deployment into something that can live on managed infrastructure, which is how you get a stack into a hardened environment without running five stateful operators yourself. The audience is a platform team that has to answer a data residency question, and the README's framing is that GroundX On-Prem requires no external dependencies when running and can therefore be used in air-gapped environments.

Node groups are split by the job the hardware does

The README spends a long section on cluster requirements, and the structure of it is the useful part. There are five named node group configurations, and the names describe the role rather than the size. eyelevel-cpu-only is the general purpose group. eyelevel-cpu-memory is for work that needs more RAM. eyelevel-gpu-layout is the group for the document layout analysis the ingest service performs. eyelevel-gpu-ranker is for the re-ranker that the search service uses. eyelevel-gpu-summary is for summarisation. The distinction between layout, ranker and summary is the whole GPU sizing question, because the three models are different sizes and an operator who treats GPUs as one bucket will either overspend or thrash. The README also has a section on chip architecture, a section on supported GPUs, and sections giving total recommended resources and the resources for each node group, plus separate guidance on the NVIDIA GPU Operator with an Azure specific installation path and an uninstall procedure.

The deployment path has a Terraform half and a Helm half

The two halves of the install are documented separately, and the README is careful about the boundary. Infrastructure creation with Terraform is only supported for AWS, and the README says that with sufficient expertise GroundX can be deployed onto any pre-existing Kubernetes cluster, which is the escape hatch for a non-AWS environment. The terraform/ directory is therefore AWS-shaped, and the README calls out two specific things inside it: access to legacy scripts, and optional EKS node diagnostics, plus a section on EKS cluster version configuration. The Helm half is the actual application deployment, with the helm/ directory holding the charts and helm-releases/ holding the release artifacts. The README also describes namespace configuration, the PV class for persistent storage, and how to use the NVIDIA GPU Operator, which are the settings that most often need changing for a particular cluster. Two structural details are worth knowing before you start: there is a service.yaml at the root, and a sample.values.yaml, which is the conventional place to override chart values. The directories involved are named plainly.

helm/
helm-releases/
terraform/
monitoring/

Autoscaling is HPA plus a custom metrics server

The README has a section on autoscaling and monitoring that explains how scaling actually works here, which is more than a stock horizontal pod autoscaler would give you. Autoscaling is enabled through HPA with per-pod HPA control, and there is a separate step to enable the custom metrics server, which is what makes the HPA target something other than CPU or memory. The custom metrics server is the interesting dependency, because a stock HPA on CPU is nearly useless for a workload that spends its time waiting on GPU work, and a metrics server that reports per-pod signals is what lets the autoscaler react to queue depth instead of CPU utilisation. Prometheus integration is listed as optional. The README also documents an optional mode for using simulated LLM responses, which is a testing affordance rather than a production one, and it is worth knowing it exists before you wire the service into a pipeline that measures answer quality.

What the open beta status and the licence actually mean

The README states plainly that the repository is in open beta, that feedback is appreciated and encouraged, and that the hosted version of GroundX is available from the vendor. It also points to a contact route for white glove support in configuring this open source repository in your environment, and for access to more performant and closed source versions. That last phrase matters for an evaluator: the open beta repository and the product it deploys are not the same thing, and the fastest performing path is described as closed source. The licence is listed as a custom one that GitHub cannot classify, with the terms in the LICENSE file, which here is LICENSE.md at the repository root, so anyone planning to redistribute or modify the deployment should read that file rather than assume a standard permissive licence. On the claims, the README asserts that in head-to-head testing GroundX significantly outperforms many popular RAG tools, with links to the vendor's own comparison posts, and names organisations including Air France, Dartmouth and Samsung with over 2 billion tokens ingested. Those are the vendor's own comparisons on its own material, so they are a starting point for evaluation rather than a verdict.

Editorial conclusion

groundx-on-prem suits an organisation that needs document parsing and search to run inside its own network boundary, in an air-gapped environment, and that already runs Kubernetes with the capacity for GPUs, since the documented node group layouts are split into CPU only, CPU memory, GPU layout, GPU ranker and GPU summary roles. It is the wrong tool for a small team that would rather use the hosted version, and it is the wrong tool for a non-AWS environment without someone willing to do the Terraform work by hand, because the infrastructure automation is AWS only. Before deploying, read LICENSE.md, because the licence is a custom one that GitHub cannot classify, size your node groups against the compute table in the README, and confirm that your image and vector storage choices, Redis, MySQL, MinIO or S3, OpenSearch and Kafka, are the ones your data residency rules allow. The last push was on 2026-10-22 and the current release is 0.2.7 from 2026-10-07.

Frequently asked questions

Official sources

1. eyelevelai/groundx-on-prem on GitHub
2. Issues
3. Project website
4. README
5. Releases