Integrations — Platform
NerveStax and Kubernetes
Run the whole product on your own cluster, with your own database and your own model.
What we do
What NerveStax does with Kubernetes
NerveStax installs on your Kubernetes with a Helm chart, against a PostgreSQL database you provide. Nothing leaves your network except the calls you configure: your warehouse, your git host and your model provider. Agent sandboxes can run as hardened pods in the same cluster, non-root with capabilities dropped and egress restricted by NetworkPolicy.
-
Install with a Helm chart
Backend, worker, frontend and a cache tier install into one namespace. Database migrations run as pre-install hook jobs, and release images are pinned to a specific build.
-
Your database, not ours
The chart does not deploy PostgreSQL. You point it at your own PostgreSQL 14 or newer with pgvector — the one component whose loss is unrecoverable stays under your backup and restore procedure.
-
Nothing calls home
No telemetry, no usage reporting, no licence check and no call-back. Outbound traffic goes only to the services you configure: your warehouse, your git host and your model provider.
-
Hardened sandbox pods
Agent sandboxes can run in your cluster as non-root pods with all Linux capabilities dropped, seccomp on, no service-account token mounted and a hard lifetime cap.
-
Egress restricted by NetworkPolicy
Sandbox egress is limited to DNS and the database and HTTPS ports a project needs, with private ranges and the cloud metadata endpoint blocked — where your cluster enforces NetworkPolicy.
-
Point it at your own model
Any OpenAI-compatible endpoint works, including a model you host yourself, so prompts stay inside the boundary along with everything else.
Background
About Kubernetes
Kubernetes is the container platform most infrastructure teams already run. For NerveStax it is both a place to install the product and, optionally, where each agent's sandbox runs.
How it connects
What connecting it looks like
-
01
Prepare the cluster
Kubernetes 1.25 or newer, Helm 3, an ingress controller, and a PostgreSQL 14+ database with pgvector reachable from the cluster.
-
02
Create the image pull secret
Registry credentials come with the release and cover every image, including the sandbox images. One registry, nothing else to allow through a firewall.
-
03
Install the release
One helm upgrade --install with your hostname, registry and database URL. Migrations run as pre-install hooks before the app starts.
-
04
Back up the encryption key
The release holds the key that protects every stored secret. Without it the encrypted columns in your database cannot be read again.
-
05
Turn on TLS
Ingress TLS is off by default. Bring a certificate or use cert-manager before anyone signs in over a real network.
Scope
What this does not cover
- TLS at the ingress is off by default in the chart. Enable it before production use.
- The sandbox tier is configured per organization and deployed alongside the main chart rather than by it; its images ship in the same registry.
- NetworkPolicy only restricts anything where your cluster actually enforces it; on hosted NerveStax, sandboxes run on a managed sandbox provider instead.
Questions
Kubernetes and NerveStax
Q01Can we run NerveStax entirely in our own network?+
Yes. The Helm chart installs the product in your cluster against your own PostgreSQL, and outbound calls reach only the services you configure — warehouse, git host and model provider. Point it at a self-hosted OpenAI-compatible endpoint and the model call stays inside the boundary too.
Q02Does the chart install a database?+
No, deliberately. PostgreSQL is the one component whose loss is unrecoverable, and you almost certainly already run one with backups, monitoring and a restore procedure. You supply the connection string; the first migration creates the pgvector extension, so the role needs permission for that or an administrator creates it first.
Q03Where do the agents run when we self-host?+
In sandboxes you run. The Kubernetes sandbox provider puts each conversation's sandbox in your cluster as a pod: non-root, all capabilities dropped, seccomp on, no service-account token, a hard lifetime and a NetworkPolicy around it. That tier is configured per organization rather than installed by the main chart.
Q04What does it cost to run?+
The defaults are modest: the four workloads request about 1.5 GB of memory in total and very little CPU, which fits a small cluster. Sandboxes are additional and short-lived — they are reclaimed when a conversation goes idle and capped at three days.
Q05Do we still bring our own model key?+
Yes, and there is no fallback key anywhere in the product. Each organization adds its own provider key, stored encrypted under an encryption key that exists only in your deployment. We never hold it and never proxy those calls.