Integrations — Model providers
NerveStax and Self-hosted models
Any OpenAI-compatible endpoint: your model, your network, your region.
What we do
What NerveStax does with Self-hosted models
NerveStax does not care whose model answers, only that the endpoint speaks the OpenAI API. Point it at a model you host, a gateway in front of one, or a regional model service under local terms, and the prompts stay inside that boundary. Self-host the product on your Kubernetes and the whole loop, including the sandbox, runs in your network.
-
Any OpenAI-compatible endpoint
Give NerveStax a base URL and a key. A self-hosted inference server, a gateway that enforces policy, or a regional model service all connect through the same path.
-
Prompts stay inside your boundary
With the product self-hosted and the endpoint inside your network, schemas, code, logs and query results never cross it. The remaining calls are the ones you configure yourself.
-
No telemetry back to us
Self-hosted, there is no usage reporting, licence check or call-back to NerveStax, and no third-party analytics or error-tracking SDKs are shipped in the product.
-
Choose the model per agent
Agents are assigned models individually, so a smaller local model can handle context lookups and alert triage while a larger one designs changes.
-
Sandboxes on your Kubernetes
The chart can run agent sandboxes as hardened pods in your cluster: non-root, no service-account token, capped lifetime, with a network policy restricting egress where your cluster enforces one.
-
Spend and usage still tracked
Calls are recorded per organization, workspace, user, conversation, agent and model, so capacity planning works the same whether you pay per token or per GPU.
Background
About Self-hosted models
Most inference servers and gateways expose an OpenAI-compatible API, whether the weights run on your own hardware or in a model service inside your jurisdiction. It is the common shape the ecosystem settled on.
How it connects
What connecting it looks like
-
01
Stand up the endpoint
Run your inference server or gateway, or get credentials for a regional model service, and confirm it answers the OpenAI chat completions API.
-
02
Add it as a provider
Enter the base URL and key in Settings under AI providers. The key is encrypted at rest and never shown back.
-
03
Self-host NerveStax
Install the Helm chart on your Kubernetes with your own Postgres, so the app and its sandboxes sit next to the endpoint.
-
04
Assign models and test one change
Map agents to models, then have one open a pull request end to end and check what left the network.
Scope
What this does not cover
- A smaller model is a real constraint, not just a cost choice. Agent surfaces are designed so the model picks between narrow options rather than inventing a plan, but capability still tracks the model you point it at.
- Some OpenAI-compatible gateways do not report token usage; where that happens, the usage page cannot show counts for those calls.
- See /pricing/ for the sovereign deployment option and /security/ for what the model receives and how secrets are handled.
Questions
Self-hosted models and NerveStax
Q01Can we use our own LLM in our own network?+
Yes. If it exposes an OpenAI-compatible API, add its base URL and key as the provider. Run NerveStax self-hosted on your Kubernetes with your own Postgres and the model call stays inside your network, along with the repository, warehouse and orchestrator traffic.
Q02What about a regional or sovereign model service?+
The same path. Anything speaking the OpenAI API can be the provider, so a model service inside your jurisdiction, under local terms, is configuration rather than a different product. You choose the region and the operator; the sovereign option on /pricing/ covers the deployment side.
Q03Does anything still leave our network?+
Only the calls you configure. Self-hosted, there is no telemetry, usage reporting, licence check or call-back to us, and tracing is off by default in the chart. Your warehouse, git host, orchestrator and model endpoint are the outbound connections, and they are the ones you chose.
Q04Do smaller models actually work here?+
They are the design target. Tool outputs are kept compact, choices are closed lists rather than free text, and risky actions stop at one approval gate, so the model decides less. It is still true that a weaker model reasons less well about an unfamiliar codebase.
Q05What does the model receive?+
Schemas and table metadata, dbt manifest, lineage and run results, repository files, command output and Airflow logs with secrets redacted, uploaded documents, alert payloads, and the rows an agent retrieves when it queries or samples a table. Result rows are not masked; /security/ sets this out in full.