On-premises
Hindsight Enterprise can run entirely on Kubernetes infrastructure you own, in your data center or on a cluster you already operate. This page is for platform and infrastructure teams evaluating an on-premises install: what runs, what you need to provide, how sizing works, and how Vectorize installs, upgrades and backs it up with you.
Who it's for
Choose on-premises when your data must stay on infrastructure you control, when your security policy rules out a third-party cloud account, or when the deployment has to run with no internet access at all. If you would rather not run Kubernetes yourself, compare Private cloud and Bring your own cloud (BYOC).
With on-premises, your team operates the cluster. Hindsight connects only to the models, storage and services you configure, and Vectorize helps with sizing, installation and upgrades.
Architecture at a glance
A single Helm chart installs the application. These are the components that run in your cluster:
| Component | What it does |
|---|---|
| API | The memory engine: retain, recall and reflect |
| Workers | Background processing: retain, consolidation, mental model refresh |
| Control plane UI | The web console your team signs in to |
| Identity service | Sign-in, with email and password or federated to your IdP through SSO |
| PostgreSQL | The application database (with pgvector), run by the CloudNativePG operator, with connection pooling |
| Embedding and reranking models | Turn text into vectors and rank recall results; run in-cluster on CPU or GPU |
| LLM | Extracts facts during retain and answers reflect; either self-hosted on your GPUs or a hosted LLM endpoint you choose |
| Hindsight Memlake (optional) | The Enterprise storage engine for memories, on your S3-compatible object storage. See Memlake |
All traffic enters through your ingress on three internal hostnames: one each for the UI, the API and the identity service.
Requirements you provide
| Area | What you provide |
|---|---|
| Kubernetes | A conformant cluster, v1.27 or later, with cluster-admin rights for the install |
| Load balancer and ingress | An ingress controller (for example ingress-nginx) whose Service gets one stable IP reachable from your network, through a LoadBalancer Service, NodePort or equivalent |
| Block storage | A dynamic ReadWriteOnce StorageClass for the PostgreSQL volumes |
| Models | GPUs for self-hosted models (NVIDIA GPUs with the GPU Operator), or a hosted LLM endpoint. Embeddings and reranking can also run on CPU, so a deployment with a hosted LLM needs no GPUs at all |
| Object storage | An S3-compatible service for PostgreSQL backups, uploaded documents and, if you use it, Memlake |
| DNS and TLS | Three internal hostnames (ui., api. and auth. under your domain) resolving to the ingress IP, a certificate covering all three, and your internal CA certificate |
| An SMTP relay for sign-up verification and invitation email | |
| Container images | Access to the image registries, or for an air-gapped install, a registry mirror inside your network |
| Monitoring (recommended) | Your existing Prometheus and Grafana |
A few details that matter at planning time:
- PostgreSQL needs three schedulable nodes. The three database instances are never placed on the same node, which is what makes a node failure survivable.
- A hosted LLM must support tool calling. Any OpenAI-compatible chat endpoint works, including OpenAI and Azure OpenAI. Reflect and consolidation depend on tool calling.
- Embeddings must be 384-dimensional. The default model,
BAAI/bge-small-en-v1.5, is. If you bring a different or external embedding model, it must match, because the dimension is part of the database schema. - Hindsight trusts your CA rather than skipping verification. Your CA is added alongside the standard public roots, so certificate checks stay on everywhere.
- The backup bucket must have no lifecycle or expiry rules. Hindsight manages backup retention itself; a bucket rule that deletes objects on its own schedule can remove files a restore depends on.
Sizing guidance
Vectorize sizes each deployment from your expected users, workload and data volume. As a starting point, this is a highly available layout for about 250 users running human-paced, retrieval-heavy agents, with self-hosted models:
| Tier | Nodes | Size (each) | GPU | Runs |
|---|---|---|---|---|
| Application | 3 | 8 vCPU / 32 GiB | None | API, workers, UI, identity service |
| LLM | 2 | 16 vCPU / 64 GiB | 1x 80 GB-class GPU (for example A100) per node | Self-hosted LLM, 2 load-balanced replicas |
| Embeddings | 2 | 8 vCPU / 32 GiB | 1x 24 GB-class GPU (for example A30) per node | Embedding and reranking models, 2 replicas |
| PostgreSQL | 3 | 8 vCPU / 32 GiB | None | 1 primary and 2 replicas |
| Total | 10 nodes | 4 GPUs |
How to read this table:
- 250 users is not 250 requests per second. Expect roughly 10 to 25 operations in flight at peak. Most operations are recall, which uses the database and the embedding model but not the LLM.
- PostgreSQL storage is driven by your data volume. Start at 500 GiB to 1 TiB of SSD per instance and grow with the corpus.
- LLM load is tunable. Hindsight limits how many LLM requests it sends at once, and Vectorize sets that limit to what your GPUs sustain.
- Fewer GPUs is a valid starting point. One LLM GPU and one embedding GPU (8 nodes, 2 GPUs) works for a proof of concept, but each model is then a single point of failure. GPU partitioning (MIG or time-slicing) does not add high availability; that takes a second physical GPU on a separate node.
- With a hosted LLM, drop the GPU tiers. Embeddings and reranking run on CPU on the application nodes, so the layout becomes three application nodes and three PostgreSQL nodes.
What Vectorize provides
- The Helm chart for Hindsight Enterprise, packaged as a single file.
- Container images, pinned to a specific validated version, with a read-only pull key for your registry mirror.
- Site configuration: Vectorize generates the values files for your site (hostnames, storage, models, high availability, backups, monitoring) and every internal secret in the right format.
- Alert rules and Grafana dashboards that register with your existing Prometheus and Grafana.
- Install assistance: a Vectorize engineer works through the install with your team, and is available for upgrades and restores.
Install process
- Requirements questionnaire. You tell Vectorize about your cluster, GPUs or hosted model endpoints, storage, networking, DNS and TLS, identity and email.
- Sizing. Vectorize proposes a node layout for your workload and confirms the model choices.
- Site values. Vectorize generates the configuration for your site. The generated files contain live secrets, so you store them in your secrets manager.
- Install together. On a call, your team and Vectorize install the operators, start the database, confirm backups are running, install the identity service, and turn on the application. Database migrations run automatically as part of the install.
- Validation. You create the admin user, then retain a document, wait for consolidation and run reflect, which together exercise every model. Before go-live you also test database failover, drain an application node, and run a restore test.
Air-gapped installs
Hindsight Enterprise runs with no outbound internet access. For an air-gapped install:
- Mirror every container image into your registry. Vectorize gives you the complete image list for your version, and the install pulls only from your mirror.
- Mirror the model weights into your network. The embedding, reranking and self-hosted LLM weights are served from an internal model mirror or pre-seeded storage instead of being downloaded from the internet.
- Use internal endpoints for everything else: your SMTP relay, your object storage, and your LLM (self-hosted on your GPUs, or an endpoint reachable inside your network).
Vectorize ships each upgrade as a new image list and chart, so you mirror the new images before the upgrade window.
Upgrades
Vectorize ships each upgrade as a new chart version and a pinned image tag. The upgrade re-applies your existing site configuration with the new chart:
- Migrations run first. Database migrations run as a pre-upgrade step. If a migration fails, the upgrade stops before any application pod changes, so the running version and the schema still match.
- Your configuration carries forward. The same site files are used for every upgrade. To change a setting, such as a model or backup retention, you edit the file and upgrade again.
- Identity service upgrades are sequenced for you. Upgrading the identity service involves a specific order of steps and a database backup beforehand. Vectorize gives you that sequence and works through it with you.
See Operations for how releases are validated and how rollback works.
Backups and high availability
PostgreSQL backups
PostgreSQL backs up to your S3-compatible bucket:
- Continuous archiving ships every change as it happens, so you can restore to any point in time within the retention window.
- A daily base backup, taken from a replica, plus one when the database first starts.
- 30-day retention by default, pruned automatically. Schedule and retention are configurable.
The bundled alert rules fire on failing or stalled archiving and on a stale base backup. Run a restore test into a separate namespace before go-live and then quarterly; it never touches production. For a production restore, contact Vectorize first so an engineer can join you.
Memlake backups
If you use Hindsight Memlake, its data is backed up separately: changes are archived continuously and a base backup of every memory bank is taken daily. Point the archive at a separate bucket, ideally on separate storage, with a credential that cannot delete. A restore is always a point-in-time clone into a new location and never overwrites live data. A Memlake restore brings back a bank's memories; the bank's configuration comes back with the PostgreSQL backup.
High-availability layout
| Component | HA layout |
|---|---|
| API | 3 replicas across application nodes |
| Workers | 3 replicas |
| Control plane UI | 2 replicas |
| Identity service | 3 replicas |
| PostgreSQL | 1 primary and 2 replicas on separate nodes, with automatic failover; read queries go to the replicas |
| Connection pooling | 2 poolers for the primary, 2 for the replicas |
| Embeddings and LLM | 2 replicas each, on separate GPU nodes (or on CPU for embeddings) |
Disaster recovery
For site-level disaster recovery, Hindsight Enterprise runs active/standby across two data centers. The standby site's database is a continuously replicated copy of the primary, and Memlake object storage is copied one way from the primary site to the standby. The standby serves read-only traffic, so you can confirm it works without risk of it diverging.
Failover is a deliberate, operator-initiated promotion: nothing promotes the standby automatically, which prevents both sites from accepting writes at once. Vectorize provides the failover procedure for your layout and works through it with you. Without Memlake, all state is in PostgreSQL and failover is simpler.
Next steps
- Compare the other options in Deployment overview.
- Read Operations for who does what after go-live.
- Book a call or contact your Hindsight representative to start the requirements questionnaire.