Why Nexus?

Nexus is the project intelligence layer for agentic development. It manages the specifications, knowledge, and configuration that your AI agents need — and makes them portable across sessions, tools, and harnesses.

Instead of rebuilding context from scratch in every conversation, Nexus provides agents with curated specification context: what has been decided, what constraints apply, and what the project knows. This is context engineering — delivering the right information at the right time in the right format.

Nexus consists of three complementary tools that work together:

• Nexus App — the web-based platform for managing projects, customers, knowledge, skills, and agent configurations.
• Nexus CLI — a command-line tool for initializing workspaces, importing existing agentic files, syncing configurations, and managing agent files locally. The CLI maintains a local .nexus/ workspace cache (automatically excluded from Git) for project metadata and linked configuration.
• Nexus MCP Server — a Model Context Protocol server that exposes 46 tool actions, enabling any MCP-compatible AI agent to read and write project knowledge directly.

Nexus is built for development teams and solo developers who use AI coding agents — such as Claude Code, OpenCode, Cursor, or GitHub Copilot — and want to move beyond unstructured prompting toward spec-driven development. It is especially valuable for teams that work on longer-running projects where architectural governance, reproducibility, and knowledge retention matter more than one-shot code generation.

Whether you are building features in legacy codebases, managing infrastructure with DevOps agents, or maintaining architectural standards across a growing team, Nexus ensures your agents work from governed specifications — not guesswork.

Nexus organizes project knowledge into structured entity types that reflect how real teams work:

• Architecture Decision Records (ADRs) — document and govern architectural choices with a full lifecycle: draft, review, accept, supersede.
• Sessions — execution history that captures what happened during a work session, including tasks created, decisions referenced, and letters exchanged.
• Vault Letters — asynchronous coordination between agents and humans with threading, acknowledgment, and audit trails.
• Research Notes & Documents — ingested project artifacts like PDFs and Markdown files that become searchable project context.
• Project Directives — scoped instructions and constraints that are automatically materialized into agent configuration files during nexus pull.
• Cross-Project Links (Enterprise) — reference and search knowledge across multiple projects to avoid duplicated effort.

This approach ensures that durable learnings live in the project knowledge base — not in ephemeral chat sessions.

Nexus supports full project document lifecycle management with S3-backed storage and CloudFront CDN delivery. You can upload offers, statements of work, and general project documents directly from the project wizard or edit view.

Uploaded documents are automatically text-extracted (direct read for .txt/.md, pdf-parse for PDFs, AWS Textract for scanned documents) and semantically indexed via vector embeddings. This means uploaded BSI requirement specs, contracts, or architecture documents become searchable by meaning — not just filename.

Nexus uses pgvector(a PostgreSQL extension) to store 1536-dimensional embedding vectors alongside every knowledge entity — ADRs, documents, research notes, planning items, and uploaded project files.

When you search via the kb_search MCP tool, three modes are available:

• Keyword— traditional text matching (ILIKE). Fast, exact, no external API call.
• Semantic— your query is converted to an embedding vector and compared against all stored vectors using cosine similarity. Finds results by meaning, not keywords: searching “firewall security” also finds documents about “nftables configuration” or “network access control.”
• Hybrid— combines both: keyword matches are boosted by semantic similarity (40/60 weighting). Best of both worlds.

Every new document, ADR, or scan report is automatically embedded in the background after creation. No manual indexing required.

Nexus supports two embedding providers, selected automatically based on the project's confidentiality classification:

• OpenAI text-embedding-3-small(1536 dimensions) — used for commercial-grade projects (public, internal, confidential). High quality, minimal cost (~$0.02 per million tokens).
• gte-Qwen2-1.5B-instruct(1536 dimensions, local) — runs on the DGX Spark hardware via vLLM. Used for classified projects where data must not leave the network. Same vector dimensionality as OpenAI — both models coexist in the same database column and index.

Nexus enforces confidentiality-aware AI routingat the code level. Every embedding generation and text extraction call checks the project's effective confidentiality level (the higher of the project and customer classification) before deciding how to process the data:

• Public / Internal / Confidential— external APIs allowed (OpenAI for embeddings, AWS Textract for PDF extraction).
• VS-NfD, VS-VERTRAULICH, GEHEIM, STRENG GEHEIM, EU-RESTRICTED and higher— all external API calls are blocked. Embeddings are generated on local hardware (DGX Spark) and text extraction uses local tools (pdf-parse, Qwen2.5-VL-7B vision OCR). No classified data ever leaves the organization's network.

Example:A project for customer “ACME GmbH” classified as VS-NfD has 5 ADRs and 6 research documents. All 11 items are embedded via the on-premise DGX Spark (gte-Qwen2-1.5B model) — zero OpenAI API calls. Semantic search works identically, but entirely within the local infrastructure.

This routing is automatic and enforced — it cannot be bypassed by configuration. The classification is inherited from the customer level, so even if a project has no explicit classification, the customer's VS-NfD status propagates automatically.

The NVIDIA DGX Spark (GB10 Grace Blackwell, 128 GB unified memory) runs three AI models simultaneously for different tasks:

• Qwen3-14B— code generation, reasoning, and agent tasks (the primary coding model).
• gte-Qwen2-1.5B-instruct— local embedding generation for classified projects. Produces the same 1536-dimensional vectors as OpenAI, enabling seamless coexistence in the same vector database.
• Qwen2.5-VL-7B— vision and OCR model for extracting text from scanned PDFs, images, and complex document layouts. Replaces AWS Textract for classified projects.

All three models are accessible through a single OpenAI-compatible API (LiteLLM proxy + Caddy), using the same endpoint format as cloud providers. The total memory footprint is 71 GB of 128 GB, leaving 57 GB headroom for concurrent inference.

Nexus communicates with AI agents via the Model Context Protocol (MCP). Any MCP-compatible agent runtime can connect to the Nexus MCP server, which exposes 46 tool actions across knowledge access, coordination, governance, and review layers.

This means Nexus works with OpenCode, Claude Code, Cursor, and any other tool that supports MCP — without being tied to a specific model or provider. The focus is on the quality of your project context, not on which model you use.

Yes. Nexus is designed to coexist with your existing agent configuration. If your project already has a .claude/ directory, AGENTS.md, or other agentic files, you have two options:

• Direct targeting— set your project's agentic root to the directory your AI tool already uses (e.g. .claude). Nexus will materialize its managed files alongside your existing ones.
• Import existing files — use nexus import to bring your existing agentic files (such as CLAUDE.md, AGENTS.md, or .cursorrules) into Nexus as managed agent files. This gives them versioning, review pipelines, and centralized distribution across your team.

The nexus init command will warn you if it detects existing agentic files in the target directory. Nexus uses a local .nexus/ workspace cache (automatically excluded from Git) to store project metadata and linked configuration — your existing files remain untouched unless you explicitly import them.

Shadow mode manages workspace file visibility in Git by adding agentic files to .git/info/exclude. When enabled, workspace files are excluded from Git tracking — useful when you want Nexus-managed agent configurations to stay local and not pollute your repository history.

You can toggle shadow mode per workspace fork in the project workspace settings, or use the CLI with nexus shadow on/off/status. Shadow mode is particularly helpful for root-level agentic files (e.g. .claude/, .cursor/) that need to exist in the project root but should not be committed.

Skills are reusable, versioned agent instructions that you can manage centrally and assign to projects. Think of them as documented playbooks that tell agents how to approach specific tasks — from code review workflows to infrastructure scaffolding.

Skills go through a lifecycle: draft, review, and activation. They can be pinned to specific versions per project and are pulled into agent workspaces via the CLI. This ensures consistency and reproducibility across your team.

The Devbox is an interactive developer shell built into the Nexus web UI. It provides a module-based environment for local development diagnostics, deployment tooling, and system inspection — directly from your browser.

Devbox modules can be managed as versioned agent files with their own review pipeline. This gives teams a shared, auditable toolkit for common development operations that works alongside their existing CLI and CI workflows.

Nexus provides centralized management for agent configuration files — such as AGENTS.md, CLAUDE.md, .cursorrules, and MCP server configs. These files are versioned, go through a review pipeline with inline comments and state transitions, and are scoped to your tenant.

When you run nexus pull, the CLI materializes the latest approved versions of these files into your project workspace. This ensures every team member and every agent session starts with the correct, reviewed configuration.

Project directives are scoped instructions and constraints that you define per project. They are automatically included when agent configuration files are generated during nexus pull, ensuring that project-specific rules — such as deployment requirements, migration workflows, or security policies — are always present in the agent context.

Directives can be managed via the web UI, the CLI, or the MCP server. They support priorities and can be toggled on or off without being deleted.

Nexus includes a notification system that keeps you informed about ADR state changes, session summaries, letter updates, and other platform events. You can configure per-topic and per-product notification preferences in your account settings.

Email notifications include one-click unsubscribe links for GDPR compliance, and all notification preferences can be managed from the settings page or via the API.

Nexus is designed with tenant isolation at its core. The platform is backed by Supabase with Row-Level Security (RLS) policies enforced at the database layer. Every query is scoped to your tenant, and project access is governed by a dual-layer RBAC model: platform-level roles and project-level roles.

All write operations use a dedicated service client to prevent silent RLS failures, while read operations go through the user client for defense-in-depth. API tokens use SHA-256 hashing at rest, and the architecture supports self-hosted deployments for organizations that need full control over their data.

Nexus uses a simple model: we charge for the managed cloud service, not for the software itself.

• Community (Cloud, Free) — a fully functional free tier for individual developers. Includes 1 customer organization, up to 10 projects, and full knowledge management. No credit card required, no time limit.
• Pro (Cloud, €6.95/mo)— for teams and professional use. Expanded limits (50 projects, 3 customers), full skill lifecycle, vault letters, audit logs, and up to 4 seats. Additional seats €2.95/month each.
• Self-Hosted (Free) — the full Pro feature set at no cost, deployed on your own infrastructure. No license key required. Docker Compose and Helm chart coming soon.
• Enterprise — adds governance features (SAML SSO, custom branding, unlimited resources) and commercial support for self-hosted installations. Contact us for pricing.

See the full plan comparison for details. If you are interested in early access or have specific requirements, feel free to reach out.

Getting started with Nexus takes just a few steps:

1. Sign up and request a demo license.
2. Install the Nexus CLI via curl -fsSL https://nexus.gatewarden.eu/install.sh | bash or upgrade an existing installation with nexus upgrade.
3. Authenticate with nexus login using your Personal Access Token.
4. Bind your workspace to a project with nexus link --project-id <id>.
5. Initialize the agentic workspace with nexus init. The CLI will create the local .nexus/ cache directory (automatically excluded from Git) and scaffold your agentic root. If existing agentic files are detected, you will be offered to import them.
6. Pull skills, agent files, and MCP configuration with nexus pull, then start your MCP-compatible agent.

Each project includes a detailed setup guide accessible from the project overview page, with copy-to-clipboard commands and source/preview mode for the full Markdown guide.

Yes — and it is free. Nexus follows an open-core model: we only charge for the managed cloud service. Self-hosted installations receive the full Pro feature set at no cost, with no license key, no phone-home telemetry, and no artificial limits.

We are currently preparing official deployment packages:

• Docker Compose — single-command full stack (coming soon)
• Helm Chart — production-grade Kubernetes deployment (coming soon)
• Terraform IaC — AWS/GCP cloud provider baseline (coming soon)
• Bare metal / Proxmox — air-gapped option (coming soon)

Self-hosted Nexus also unlocks features that are technically impossible in a cloud deployment — most notably, semantic search for classified content. See “How does self-hosting unlock AI features for classified projects?” below.

Enterprise customers who self-host can add a commercial support agreement for SLA-backed assistance, priority patches, and upgrade guidance. See self-hosting options for details.

On Nexus Cloud, projects classified as VS-NfD, GEHEIM, EU-RESTRICTED or higher cannot use external AI APIs (OpenAI, AWS Textract) for embedding generation or document text extraction. This is by design: sending classified content to a third-party API would violate handling rules regardless of data protection agreements.

On Nexus Cloud, classified projects therefore fall back to keyword search only. Semantic search and cross-project search for those projects are unavailable.

Self-Hosted Nexus changes this entirely. When you deploy Nexus on your own infrastructure alongside a local AI stack, all AI processing stays on-premise:

• Local embedding model(e.g. gte-Qwen2-1.5B-instruct on a GPU node) embeds classified documents without any external API call. The 1536-dimensional vectors are identical in shape to OpenAI embeddings — the same pgvector HNSW index serves both.
• Local vision OCR (e.g. Qwen2.5-VL-7B) extracts text from scanned PDFs and images. Classified documents are never transmitted outside your network.
• Full semantic searchon all projects including VS-NfD — cross-project search returns classified results alongside normal results, access-controlled by project membership.
• Air-gapped operation— the entire stack (Nexus, PostgreSQL/pgvector, embedding model, LLM) can run without internet access. Suitable for SINA, isolated networks, or high-security data centres.

Example:A defence contractor running self-hosted Nexus with an NVIDIA GPU node can semantically search across VS-NfD-classified requirements documents, BSI compliance reports, and architecture decisions — all locally, with no cloud dependency.

In short:Nexus Cloud is the right choice for unclassified and confidential workloads. Nexus Self-Hosted is the right choice when you need full AI capabilities — including semantic search — for VS-NfD or higher classified content.

Nexus is not venture-backed and does not serve shareholder returns or dividends. Revenue from the managed Cloud SaaS edition (Pro and Enterprise plans) is used exclusively to cover two things:

• Operational costs — hosting, database infrastructure, CDN, backups, monitoring, and support staff for the cloud service.
• Continued development — engineering time invested in the open-source stack, new features, security patches, and documentation that benefits all users (cloud and self-hosted alike).

When you pay for the cloud edition, you are funding the maintenance and evolution of the entire platform — including the free self-hosted version. This is a sustainable open-core model, not a profit extraction mechanism.

Nexus is actively evolving. Current areas of focus include expanding the pgvector semantic search with context-aware retrieval for agent sessions, interactive import prompts during workspace initialization, expanded cross-project coordination features, deeper CI/CD integration, and additional agent runtime support.

For the full roadmap, visit the Roadmap page.