Give every agent the project context it is missing.

A project intelligence layer for agent-assisted development. Nexus manages the specifications, decisions, documents, instructions, and coordination records that AI agents need to work reliably on a project.

It sits above the agent runtime. Tools like OpenCode or Claude Code execute work; Nexus provides the governed project context they work from. The platform consists of a web application, CLI (nexus-cli), MCP server (nexus-mcp), hardware agent (nexus-link), and runtime plugins (nexus-runtime-plugins). All tools are open source.

Nexus is most useful when AI-assisted work extends beyond a single prompt or short-lived prototype. Typical users include:

• Solo developers maintaining long-running projects
• Engineering teams that need consistent agent instructions
• Architects who want decisions and constraints to remain traceable
• Platform and DevOps teams working across environments
• Organizations that need self-hosting, access controls, or local AI processing

For a one-off experiment with no durable project context, Nexus may be more structure than you need.

No. Nexus is not another coding-agent interface. OpenCode, Claude Code, Cursor, and GitHub Copilot run models and execute tasks. Nexus manages the durable project information around them: approved decisions, directives, documents, skills, role profiles, session outcomes, and coordination records.

You continue to work in your preferred agent runtime. The main difference is that important project context is prepared and governed before the agent needs it:

1. The team records an architectural decision or project rule in Nexus.
2. The approved information is synchronized into the workspace via nexus pull.
3. The agent uses it while planning, implementing, or reviewing work.
4. New durable findings are written back to the project knowledge base.
5. Future sessions reuse that context instead of starting again.

An agent memory server primarily stores and retrieves information from earlier sessions. Persistent memory is also part of Nexus, but Nexus extends it with project governance and coordinated execution.

Nexus additionally provides:

• Named and reusable Actor profiles
• Structured Dispatch between Actors, users, and projects
• Main-project and subproject relationships
• ADR review and voting
• Project roles and notifications
• Governed agent configuration
• Private AI hardware registration and command control

Memory tells an agent what happened before. Nexus also helps determine who should act next, where the work belongs, how it is reviewed, and which infrastructure may process it.

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.
• Nexus Dispatch - structured, routed work items for agent-to-agent and agent-to-human coordination. 8 dispatch types, 9 lifecycle statuses, cross-project routing, and an append-only audit trail.
• 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 communicates with AI agents via the Model Context Protocol (MCP). Any MCP-compatible agent runtime can connect to nexus-mcp, which exposes 60+ tool actions across knowledge access, coordination, governance, and review layers.

Supported runtimes: OpenCode and Claude Code. Each project selects one executioner, OpenCode (the default) or Claude Code, and nexus run starts whichever the project selects. The core Nexus plugins (Session Guard, Headroom Intercept, Compaction Plus, Routing Guard, Cost Control) run as OpenCode plugins and as Claude Code hooks.

Claude Code since v0.14. Claude Code projects get Nexus-managed rules, statusline, settings, and an optional terminal workspace with a usage panel. An experimental Claude Max execution mode, enabled per user, runs work on the user's own Claude subscription; Nexus stores no Claude credential.

Other MCP-compatible tools (Cursor, GitHub Copilot, etc.) can connect to nexus-mcp but receive no dedicated integration work at this stage.

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 levels protect public repositories. With level ai, nexus pull adds every agent file it writes to .git/info/exclude, and agents get a rule not to reveal AI-assisted development in commits, pull requests, code comments or repository docs. Level nexus also forbids Nexus references (ADR numbers, task and session IDs, Nexus tool names).

Set the level in the project rules form or with nexus env set. With nexus-cli 0.28.16, nexus shadow check scans commit messages and tracked files against the central patterns, and a commit-msg hook (on by default) blocks commits that would leak them. Switching shadow on does not clean content that is already 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.

Architectural decisions and agent instructions should not remain inside one developer's private chat context. Nexus turns them into shared, reviewable project assets.

Team members can be invited to projects with scoped roles (admin, editor, reviewer, viewer). Each role determines what a member can view, modify, or approve. Agents act under delegated identity: their actions remain attributable to the human user who configured them.

Yes. Architecture Decision Records follow a formal lifecycle: draft, review, accept, or reject. Any team member with reviewer or higher permissions can comment on an ADR under review and cast an accept or reject vote. The decision outcome, rationale, and vote history are preserved permanently.

When an agent performs actions through the Nexus MCP server, it operates under the authenticated user's identity and project permissions. The agent cannot exceed the user's role boundaries. Session entries, ADR drafts, task updates, and Dispatches all record which user (and which agent toolstack) produced them.

ADR state changes (submitted for review, accepted, rejected), Dispatch assignments and resolutions, team invitations, role changes, and session summaries. Notifications are delivered via email with one-click unsubscribe. Per-topic preferences are configurable in account settings.

Nexus uses dual-layer RBAC: platform roles control organization-level access, project roles control per-project access. Project roles (admin, editor, reviewer, viewer) determine who can create ADRs, modify directives, manage Actors, or only read project knowledge. Agents inherit the permissions of the user who authenticated them.

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 follows an open-core model: the software is free and open. You only pay for the managed cloud service.

• Community (Cloud, Free) - fully functional for individual developers. 1 organization, up to 10 projects, full knowledge management. No credit card, no time limit.
• Pro (Cloud, €6,95/mo) - for teams and professional use. 50 projects, 3 organizations, full skill lifecycle, cross-project dispatch, audit logs, and up to 4 seats. Additional seats €2,95/month each.
• Self-Hosted (Free, open-core) - the full Pro feature set at no cost, deployed on your own infrastructure. No license key, no phone-home telemetry, no artificial limits. A Helm chart for Kubernetes (RKE2 reference, CloudNativePG database) is planned for v0.18.0 (Q1 2027), with Docker Compose as the single-node alternative. Recommended for classified workloads and air-gapped environments.
• Enterprise - adds SAML SSO and commercial support SLA for self-hosted. Contact us for pricing. Enterprise features are not required for most use cases - the self-hosted open-core edition covers everything else.

See the full plan comparison for details.

nexus-link is the open-source hardware agent that connects on-premise AI nodes (NVIDIA DGX Spark, A100, H100) to the Nexus platform. It runs two processes on the device:

• nexus-link-agent - pushes live telemetry (GPU temperature, utilization, power, system CPU/RAM/disk, Docker container health) to the Nexus backend every 30 seconds.
• nexus-link-service - a lightweight Axum HTTP server on port 8443 that receives signed compose management commands from the Nexus dashboard.

Install via curl -fsSL https://nexus.gatewarden.eu/install-link.sh | bash. Source at github.com/gwnexus/nexus-link (Apache-2.0).

nexus-link uses two independent credentials with different trust levels:

• Node token (nxs_node_*) - used by the long-running telemetry agent. Read-only by design: pushes metrics and sends heartbeats. Supports a 24-hour rotation grace period so the device never loses connectivity during a token change.
• Command token (nxs_cmd_*) - exclusively used for compose management (file read/write, docker compose up -d, log streaming). Write-capable. Rotated immediately with no grace period. Stored AES-256-GCM encrypted in the backend - never sent to the browser.

This separation means a compromised telemetry process cannot trigger service restarts or modify configuration files. Both tokens are generated and displayed once in the registration wizard.

Write operations to hardware nodes are cryptographically signed. The dashboard signs commands with Ed25519; the device verifies the signature before executing. A timestamp window and nonce prevent replay attacks.

View technical details →

No. nexus-link is designed for private-network deployments. At registration, the CLI automatically detects the device private IP via ip route get 1.1.1.1 and reports it as the service endpoint. The backend stores this as the node address - no DNS entry or reverse proxy required.

The recommended setup is to access the Nexus dashboard from a machine on the same WireGuard VPN or LAN as the hardware node. The dashboard proxy routes forward API calls from your browser to the device through the private IP. Public internet exposure of port 8443 is not recommended while the security audit is in progress.

The AI Hardware node detail page has a Compose tab where you can view and edit Docker Compose files, save changes with automatic YAML validation and git commits, activate the configuration on the device, and stream container logs in real time.

View technical details →

Nexus stores vector embeddings alongside every knowledge entity (ADRs, documents, research notes, and uploaded files). You can search by keyword, by meaning (semantic), or both combined (hybrid). New content is automatically indexed in the background - no manual steps required.

View technical details →

Nexus supports both cloud and local embedding models. The provider is selected automatically based on the project's confidentiality classification - cloud APIs for standard projects, on-premise models for classified content. Both produce compatible vectors that coexist in the same database and index.

View technical details →

Nexus enforces confidentiality-aware AI routing at 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.

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.

Soon, and it will be free. Self-hosting is planned for v0.18.0 (Q1 2027). 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:

• Helm Chart: full stack on your own Kubernetes, RKE2 reference, CloudNativePG (v0.18.0)
• Docker Compose: single-node alternative (v0.18.0)
• Terraform IaC and bare metal / Proxmox (later)

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 search on 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 (planned for v0.18.0) will be 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.

Next is v0.18.0 (planned for Q1 2027): a self-hosted stack with a Helm chart on Kubernetes (RKE2 reference, CloudNativePG), multi-tenant support with organization-scoped URLs, deeper Nexus Spark (bring your own hardware) integration, and sharper cost control. v1.0.0-beta follows in Q2 2027.

For the full roadmap, visit the Roadmap page.