A short list to review: what a foundation4 deployment contains

Someone has to approve every new system on a sensitive network. That person needs to know what will run, what it stores, what it talks to and which secrets it holds. The shorter and better documented that list is, the shorter the review.

This post is that list for a foundation4 installation on Kubernetes. Each section links to the foundation4 docs page that describes it, so a reviewer can check every point at the source.

Two charts, one namespace

A foundation4 installation is two Helm releases in one namespace. The docs call them the core release and the application release.

Chart	What it installs
Core	NATS JetStream (three servers and a utility pod for operator commands), Valkey as the Redis-compatible cache, a Prometheus server, and optionally a bundled PostgreSQL for evaluation. It also writes the Secret that carries connection settings and application values.
Application	The API server, the workers, the dashboard, three installation Jobs, and optionally an Ingress or an HTTPRoute for a Gateway.

The charts include every dependency chart, so installation needs no access to public chart repositories. A cluster without internet access pulls every image from a private registry that the operator mirrors in advance, as the charts and images page describes.

That table is the whole application footprint. There is no separate vector database and no search cluster. Production uses an external PostgreSQL database that you run and secure.

What each component does

API server. The API server receives every external request. It serves the REST API, the OpenAPI description and Prometheus metrics. For ingestion, it validates the request, records the document in PostgreSQL and places the text on the work queue. The docs describe it as stateless for the REST API, so capacity grows by adding replicas.

Workers. The workers run the same binary as the API server, started in worker mode. Each worker takes documents from the queue, splits each one into fragments, computes embeddings and writes fragments, vectors and full-text index entries to PostgreSQL. Workers scale separately from the API server.

gRPC service (sidecar). Some text splitters and embedding libraries exist only as Python packages. A Python gRPC service hosts them. It runs as a sidecar, a second container in each API server pod and each worker pod, and the main process reaches it on the pod's loopback interface. Model weights and Python packages are supplied to this container as container image volumes.

NATS JetStream. NATS JetStream is the work queue between the API server and the workers. Its object store holds the raw text of a document until a worker processes it, for at most 24 hours. The three NATS servers keep their data on persistent volumes.

Redis-compatible cache (Valkey). The cache holds short-lived data only: encrypted results of API key verification and frequently read objects such as pipelines. It keeps data in memory, with no volume. The architecture page states that it contains no data required for recovery.

PostgreSQL with pgvector. PostgreSQL is the primary data store. It holds pipelines, documents, versions, API keys, permissions, fragments, vectors and full-text indexes. The pgvector extension provides vector storage and search. Production uses an external database; the bundled one stores data on a temporary pod volume and is for evaluation only.

Dashboard. The dashboard is a web application served at /dashboard on the same host as the API. Operators sign in to it with an API key and secret. If no operator uses it, the checklist says to turn it off.

Installation Jobs. Three Jobs run as Helm hooks before the services start, including the database migration and the creation of the master key, the administration key of the installation. They run the API server image and then exit.

Prometheus. The core chart includes a Prometheus server that scrapes metrics from the API server and the workers. You can use it or point your cluster's monitoring stack at the same metrics. The API server can also export OpenTelemetry traces. The monitoring and logging page covers both.

The foundation4 images are built for amd64 nodes.

What holds state, and what does not

This decides your backup plan. The docs answer it in one sentence: the complete persistent state of a deployment is the PostgreSQL database, the application secret, and the identifier and secret of the master key.

Component	Holds state?	Notes
PostgreSQL	Yes	Everything you would restore
Application secret, master key	Yes	Kept in your secret store, outside the cluster
NATS JetStream	Work in progress only	Raw text waits here until a worker processes it, for at most 24 hours
Valkey	No	Short-lived caches in memory, rebuilt automatically
API server, workers, gRPC sidecar	No	Replaceable pods
Dashboard	No	Serves files
Prometheus	Metrics only	Its own volume

A restore therefore needs the database backup and the application secret and master key that were in effect when the backup was taken. The backup, restore and upgrades page gives the procedure.

On encryption, briefly: stored text is encrypted with a separate key for each classification, which separates content by classification inside the database. The application secret encrypts a smaller set of values, such as the API keys of registered model servers. The data protection page covers both in detail.

Network paths

The docs list every connection the charts and the code use. Anything not on this list can be denied.

From	To	Purpose
Ingress controller or Gateway	API server pods	API requests
Ingress controller or Gateway	Dashboard pods	Dashboard
API server, workers, installation Jobs	PostgreSQL	Primary data store
API server, workers, installation Jobs	Valkey	Cache
API server, workers, installation Jobs	NATS JetStream	Queue and object store
NATS JetStream	NATS JetStream	Routes between the three servers
Prometheus server	API server and worker pods	Metrics
Prometheus server	Kubernetes API	Pod discovery
API server, workers	Your model servers	Embedding and generation requests
Every pod	Cluster DNS	Name resolution

Model traffic goes only to the model servers an administrator registers. foundation4 works with any OpenAI-compatible model. Your content stays inside your perimeter, with one condition: it leaves only if an administrator registers a model server outside the perimeter. The docs ask for internal endpoints, listeners that accept only cluster addresses, and https:// URLs on any network shared with other systems.

foundation4 is built for isolated networks, with a qualifier: some embedding models and the token splitter download files on first use. The models and packages page lists what works offline. The policy set in the docs allows no connection to the internet.

Hardening the operator applies

The charts install a working system, and most hardening measures are off by default. The operator applies them. The security hardening page lists each measure, where it is configured and what the chart does by default.

TLS at the edge. The API server and dashboard serve plain HTTP inside the cluster. TLS for clients and browsers ends at the ingress controller or the Gateway, with a certificate you issue for your host name.

TLS to PostgreSQL. A production deployment connects with sslmode=verify-full, which encrypts the connection and checks that the certificate is signed by a trusted authority and issued for the database host name. A private certificate authority goes in the configuration. The connection URL looks like this:

POSTGRES_URL=postgres://<user>:<password>@<database-host>:5432/<database>?sslmode=verify-full

A query on pg_stat_ssl then confirms that every foundation4 session uses TLS.

Network policies. The charts ship no policies for the foundation4 pods. The docs supply a set of ten, starting with a default deny for all traffic in the namespace, then allowing only the paths in the table above:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Pod security. The namespace enforces the baseline Pod Security Standard and reports violations of the restricted standard as warnings. The docs give values that restrict privilege escalation and system calls for the foundation4 containers.

Service account tokens. The foundation4 processes make no calls to the Kubernetes API, so they need no service account token. The docs turn off token mounting for the foundation4 service accounts and the namespace default. Only the Prometheus server keeps its token, for pod discovery.

Paths without an API key. The API server answers a few routes without a key: the root, the health check, the metrics and statistics routes, and the API documentation. The docs restrict the monitoring routes at the ingress or Gateway to the monitoring and operator networks.

API keys. The server checks each request's API key and its permissions on each object. The docs ask for one key per client application, an expiry date and a rotation schedule for each key, and a regular review of the key list. The master key is for administration only.

The secret inventory

foundation4 holds a short list of secrets. Each protects one thing.

• Database credentials let foundation4 connect to PostgreSQL.
• The cache password protects the bundled Valkey.
• The application secret encrypts the stored API keys of registered model servers and some cached values. A restore needs the one that was in effect at backup time.
• The master key is the administration key. Its identifier and secret are fixed after the first installation, and the API server and workers check it at every start.
• The TLS certificate and key for your host name live at the ingress or Gateway.
• Image pull credentials let the cluster pull from your registry.

The docs set the handling rules: keep the secrets file in your organization's secret store and out of version control, keep credentials out of Helm values, encrypt Kubernetes Secrets at rest, and limit read access to Secrets and pod exec to the operators. The secrets and keys page has the full inventory.

The production readiness checklist

The production readiness checklist is written for operators and for security reviewers. Each check names a command or setting and the expected result, so it doubles as evidence. Highlights:

• Database. External PostgreSQL in use, TLS with certificate checks, pgvector installed, a connection budget that fits, scheduled backups and one completed restore test.
• Secrets. Template passwords replaced, the secrets file outside version control, recovery copies in the secret store, Secret access limited to operators, Secrets encrypted at rest.
• Capacity. A memory limit on every foundation4 container, planned storage classes, headroom on the queue.
• Monitoring. Worker metrics collected, alerts on failed documents and queue age, logs kept outside the pods.
• Security. TLS at the ingress or Gateway, one API key per client application, log level at warn, network policies including the default deny, baseline pod security, service account tokens off, the dashboard off when unused, model servers on internal addresses only.
• Availability. Two or more API server replicas, disruption budgets, NATS servers spread across nodes, and a runbook that restarts the services after each configuration change.

Why a small footprint helps

A review slows down with every component nobody can explain. foundation4 keeps the list short: two charts, one database, one queue, one cache, one metrics server and the application pods. Every network path and secret is written down, with checks that prove the configuration.

If you are preparing an installation review and want to walk through this list with us, request a briefing.