Skip to Content
Self-HostingSelf-Hosted & Sovereign

Self-hosted & sovereign

Nexora runs entirely on infrastructure you control. There is no Parendum-hosted endpoint that the agent product calls to do its work — when you deploy Nexora (or NexoraCloud) into your VPC, data center, or air-gapped network, your data, credentials, and the systems your agents touch all stay inside your perimeter.

Self-hosting is not a chore you tolerate to use Nexora. It is the point.

The agent product is self-hosted only. The supporting SaaS Parendum runs (the marketing portal, license gateway, documentation, and package marketplace) never sees your conversations, your knowledge base, or your production systems.

Data sovereignty

When an agent reads a document, answers a question, or calls a tool, the inputs and outputs of that work stay on your network. Prompts, uploaded files, knowledge-base embeddings, conversation history, and tool results live in your PostgreSQL and Redis instances — not on a third party’s servers.

This matters because cloud agent services route everything through their infrastructure:

  • With the OpenAI Assistants API or Microsoft Copilot Studio, your prompts and documents transit (and may be retained by) that provider’s cloud.
  • With Nexora, the orchestration layer is yours. The only data that leaves your network is whatever you explicitly send to an LLM provider — and even that is optional (see bring-your-own providers).

Regulatory and compliance fit

For regulated industries — healthcare, finance, government, defense — “the AI never sees an outside cloud” is often a hard requirement, not a preference.

Self-hosting Nexora keeps you in control of:

  • Data residency — run in the exact region, jurisdiction, or facility your rules require.
  • Air-gapped deployment — Nexora can run with no public internet egress at all when paired with fully-local model providers.
  • Auditability — the core is open-source (MIT), so you can inspect exactly what the platform does with your data. NexoraCloud adds SOC2-oriented retention controls, GDPR export, and audit logging.
  • Access governance — multi-tenant auth, TOTP 2FA, and (in NexoraCloud) SAML SSO, SCIM provisioning, granular RBAC, and IP allowlisting.

Because nothing is delegated to a third-party SaaS, your compliance boundary is your own infrastructure — a boundary you already understand and audit.

Production-access safety

Agents are most useful when they can actually do things — query a database, deploy to Kubernetes, page an on-call engineer, write to S3, browse internal tools. Nexora ships ~90 builtin tools and ~15 skills for exactly this.

That power is also why where the agent runs matters. An agent holding credentials to your production systems should execute inside your perimeter, not on a third party’s SaaS:

  • Credentials and secrets are stored encrypted (Fernet) in your own database and never handed to an outside service.
  • Tool calls that reach internal systems originate from inside your network — no inbound tunnel from a vendor cloud to your production estate.
  • The hardened http_request tool enforces an SSRF allowlist you define.

If the agent lived in someone else’s cloud, granting it production access would mean granting that vendor a path into your most sensitive systems. Self-hosting removes that class of risk entirely.

No per-token markup

Nexora connects directly to LLM providers using your own API keys (or your own local models). There is no Nexora-imposed per-token margin on inference, and no usage-based metering of the orchestration layer skimming your token spend. You pay your model provider their rate, full stop. NexoraCloud is licensed per instance, not per token.

Bring-your-own model providers

Nexora speaks to roughly 45 providers — Anthropic Claude, Google Gemini, OpenAI, AWS Bedrock, Azure OpenAI, Google Vertex, and many more — so you are never locked to one vendor. You can mix providers per agent and configure fallback chains.

Crucially, you can also run fully local models with no external API at all:

  • Ollama — local open-weight models on your own hardware.
  • LMStudio — local model server with an OpenAI-compatible API.

Paired with a local provider, a self-hosted Nexora instance can operate with zero outbound calls to any AI cloud — the prompt, the model, and the response all stay on machines you own. This is the strongest form of sovereignty: the AI literally never sees an outside network.

You own your security posture

Self-hosting means you also own the controls — which is a feature for teams that need to. Nexora’s agents can spawn containers to execute tools (the backend mounts the Docker socket for sandboxed execution), and you decide how that isolation is configured for your environment:

  • You control the Docker host, the sandbox boundaries, network policies, and resource limits.
  • You decide what tools agents may run and against which systems (SSRF allowlist, tool permissions, local-execution grants).
  • You harden, monitor, and patch the deployment on your own schedule.

With control comes responsibility. The backend image installs CLI tooling and mounts the Docker socket so agents can spawn execution containers. Review the Production Configuration hardening checklist before exposing an instance, and treat the Docker host as a privileged boundary.

This is the trade self-hosting offers: instead of trusting a vendor’s opaque security model, you operate within the security posture you already maintain and audit.

Getting started

ChannelsDocker Deployment