otal-labs/nexul

> One loop from docs to deploy, on servers you own.
> [!WARNING]
> Nexul is in beta. Expect rough edges and breaking changes between releases. Proceed with caution before trusting it with production work.
Nexul is a self-hosted platform for teams that ship software with coding
agents in the loop. Docs, tickets, chat, CI runners, and deploys to your own
servers live in one place, and one MCP server exposes all of it, so an agent
works through the same tools people do.
Alternative to
One install covers what these do, area by area:
| Area | Instead of |
|---|---|
| Project management | Linear, Jira |
| Docs | Notion, Confluence |
| Chat and calls | Slack, Discord |
| Deploys | Heroku, Vercel, Netlify, Render |
| CI runners | GitHub Actions self-hosted runners |
| The agent layer | One MCP server over all of the above, instead of bolting an agent onto each tool |
Phew, that is a lot of tabs to close.
Where the idea comes from
Three repositories shaped Nexul.
mattpocock/skills showed how short
the path from an idea to a set of scoped tickets can be: grill the idea
against the docs, map it, and the tickets fall out. A developer gets from
"I think we should" to a board of work in one sitting.
pingdotgg/t3code showed how natural it
is to run several pieces of work in parallel once an agent does the typing,
and how much that changes the way code should be written.
pstack, Lauren Tan's
engineering-discipline pack, showed how far short principle skills and
playbooks go when an agent checks its own work against them.
Nexul takes all three ideas and applies them to the whole software delivery
loop, from the doc to the deploy, on your own servers.
The core idea
Every piece of work is linked and searchable in one place: docs, tickets,
code, reviews, deploys, server topology, and run logs. One MCP server exposes
all of it, so an agent can run the whole loop without leaving the system.
Every step is a use case. The web app reaches the use-case layer through an
HTTP gateway, and MCP exposes its registered tools through the same layer. A
personal access token carries the user's permissions, and calls made through
it are attributed to that user. The adapters are separate surfaces over one
source of behavior.
Who it's for
- Solo developers and small teams who self-host and want one install command
and native services on one port, with no managed services.
- Teams that run coding agents and need a tracker, docs, and deploys that a
machine can query and act on.
- Operators who deploy to a mix of ordinary servers and want a live topology
view without running Kubernetes.
Functions
Everything below is in the AGPL edition and runs on your own servers. The
guide covers each area.
| Domain | Done | Summary |
|---|:---:|---|
| Workspaces and projects | ✅ | One instance hosts several workspaces, each with its own projects, members, and settings. A project owns its docs, its board, and its repositories. |
| Docs | ✅ | Rich text with version history, named versions, @ mentions of tickets and docs, attachments, and markdown import and export. Docs are the source of truth tickets derive from, and each doc has one thread where its work is discussed. |
| Live collaboration | ✅ | Several people edit one doc at once with live cursors and merged edits, and the UI updates over WebSockets without a refresh. |
| Tickets and the board | ✅ | A Kanban board per project with configurable statuses in five fixed stages, ticket types, labels, and swimlanes. A ticket links to branches and pull requests and counts as finished once a linked PR is merged and none are still open. |
| Chat | ✅ | Channels, direct messages, and one thread per ticket and per doc, laid out as sidebar, list, and thread. Mention a person or @Agent, and the events you care about land in an inbox. |