Mothership Overview

Your team's code hub, running on your own hardware. No cloud. No third party. No compromise.

Overview

Mothership Mode is Aura's answer to a question most teams have stopped asking: what if your source of truth didn't live on someone else's servers?

Every commercial code collaboration tool — GitHub, GitLab SaaS, Bitbucket Cloud, and the newer wave of AI-native platforms like Cursor's cloud agents — shares one structural property: your code leaves your network. It is copied, indexed, analyzed, and often fed into model training pipelines. For most teams, the trade is worth it. For teams working on regulated systems, defense contracts, proprietary trading logic, medical devices, or simply anything they would rather not hand over to a third party, it is not.

Mothership Mode is the alternative. It is an embedded, self-hosted, peer-to-peer team hub that runs as part of the Aura binary. You already have it. You just need to start it.

What Mothership Is

A Mothership is a long-running Aura process that acts as a coordination point for a team of developers. It handles:

Peer registration and authentication via signed join tokens.
Function-level sync of changed AST nodes between peers, not diffs of text files.
Intent log replication so every teammate sees why a change was made, not just what changed.
Cross-branch impact alerts when a function you depend on is modified on someone else's branch.
Team messaging between humans and between AI agents working in the same repository.
Zone ownership so two developers (or two AI agents) don't step on each other's files.

The key word is embedded. There is no separate server product to install. The same aura binary you use on your laptop can act as a Mothership if you tell it to. It speaks the same protocol whether it is acting as a peer or as a hub.

Why P2P, Not Client-Server

Most self-hosted Git platforms — Gitea, GitLab CE, Forgejo — are classic client-server. There is one authoritative server. Clients push and pull from it. If the server dies, the team stops.

Mothership is different. It is a peer-to-peer network with a coordinator role, not a hub with dumb spokes. Concretely:

Every peer holds a full replica. Function bodies, intents, and history are mirrored to every connected peer via the write-ahead log. A Mothership is a convenient meeting point, not the single source of truth.
Peers can talk directly. After the initial JWT handshake, two peers can establish a direct TLS channel and sync without routing through the Mothership. This matters for bandwidth inside an office LAN and for latency-sensitive pair-programming scenarios.
Motherships can federate. Two Motherships can peer with each other to form a mesh. A global team can run one Mothership per region without anyone being a second-class citizen. See team topologies for the shapes this can take.
A Mothership going down does not stop work. Peers keep working offline, buffer changes in a local WAL, and reconcile when the Mothership or a sibling peer comes back online.

This is a deliberate design choice, not an accident of implementation. A client-server model concentrates risk — one misconfigured box, one hostile actor with root on that box, and the entire team's history is compromised or gone. P2P distributes that risk across every peer.

The Sovereignty Story

There is a specific phrase we use internally: the code never leaves the network.

When you start a Mothership on a laptop in your office, and your teammates join it from their laptops, the following things are true:

Function bodies are transmitted between peers over TLS.
The TLS certificate was generated by the Mothership itself, or issued by a CA you control. There is no Anthropic, no Aura Inc., no vendor involved in the handshake.
Join tokens are signed by the Mothership's private key, which never leaves the Mothership's disk.
The intent log — the record of why each change was made — is replicated peer-to-peer. It is never uploaded to an analytics endpoint.
If you use AI agents (Claude, Cursor, Aider) alongside Aura, the agents run on the developer's own machine or via the developer's own API key. Aura does not proxy prompts through a vendor.

This is not a marketing claim. It is a property of the architecture. The Aura CLI has no hardcoded endpoints it phones home to when Mothership Mode is enabled. The only network traffic is peer-to-peer and peer-to-Mothership, over addresses you configure.

Security callout. Self-hosting does not automatically make you secure. It moves the responsibility to you. Read TLS and JWT before exposing a Mothership to the public internet, and follow the rotation guidance in join token security.

How Mothership Compares

| Property | Mothership | GitHub Enterprise Cloud | GitLab Self-Hosted | Gitea | Cursor Cloud Agents | |---|---|---|---|---|---| | Code stays on your network | Yes | No | Yes | Yes | No | | Self-hosted | Yes (any box) | No | Yes (heavy) | Yes (light) | No | | P2P sync between peers | Yes | No | No | No | No | | Function-level (AST) sync | Yes | No | No | No | Snapshot-based | | Intent log replication | Yes | No | No | No | No | | Works offline and reconciles | Yes | Limited | Limited | Limited | No | | License | Open source | Proprietary | Open core | Open source | Proprietary | | Per-seat fee | None | Yes | Yes | None | Yes |

Mothership is not trying to replace every feature of GitHub. It does not have pull-request-style review UX, issue tracking, or CI runners. It is trying to replace the sync and collaboration core — the part where your code actually moves between teammates — with something you control.

Teams typically run Mothership alongside a lightweight issue tracker (Linear, GitHub Issues used only for metadata, or a self-hosted Gitea) and their own CI. The code itself — the part that matters — lives on their hardware.

How Changes Flow

The high-level flow for a single change looks like this:

developer A                 Mothership                 developer B
-----------                 ----------                 -----------
edit function     -->       WAL append       -->       WAL apply
log_intent        -->       intent replica   -->       intent replica
auto-sync push    -->       fanout to peers  -->       AST patch apply
                                                       impact alert
                                                       (if A's change
                                                        touches B's deps)

Developer A edits a function and logs an intent. Aura automatically pushes the changed function body to the Mothership. The Mothership fans the change out to every connected peer, including Developer B. If B's branch depends on the function A just changed, Aura raises a cross-branch impact alert on B's machine.

No diff is ever resolved at the text level. The unit of sync is the AST node. This is why merge conflicts are rare in Aura — two developers editing different functions in the same file produce independent node updates, not competing text hunks.

When to Use Mothership

You want Mothership if:

Your code cannot legally or contractually leave your network.
Your team is tired of paying per seat for features you do not use.
You want tight integration between Sentinel (AI agent coordination) and your VCS hub.
You want function-level sync and impact alerts, not text diffs.
You want a single binary, not a Kubernetes deployment.

You may not need Mothership if:

You are a solo developer with no collaboration needs.
You are happy with GitHub and do not care about sovereignty.
You need heavy enterprise features — LDAP group sync, SAML, audit retention for compliance regimes — that Mothership does not currently ship. Check the roadmap; several of these are landing post-v0.12.

Version and Stability

Mothership Mode shipped in v0.11.0 (March 2026). The protocol is versioned; Motherships and peers negotiate a common version at handshake time. Backward compatibility is maintained within a major version. The current wire protocol is stable enough for production use; we are running a fleet of Motherships ourselves and have tested teams up to 500 peers. See scaling for sizing guidance.

A Brief History of the Problem

For twenty years, the history of source control has been a history of centralization creeping in, despite the protests of the tools themselves.

Git shipped in 2005 as the distributed version control system. Every clone was a full repository. There was no server in the design. Within three years, GitHub had convinced the world that the natural place for Git repositories was on one company's servers. Within ten, that company was Microsoft. Within fifteen, AI assistants were trained on every public line. The tool is still distributed; the practice is not.

Every wave of "new VCS" since has started by promising sovereignty and ended by selling hosting. Mercurial, Bazaar, Fossil — all eclipsed by the convenience of a hosted service. GitLab and Gitea let you self-host, which is good, but both are client-server in architecture; the "server" part still reflects the old model.

Mothership is not the first attempt to take sovereignty back. It may not be the last. It is distinctive in one respect: it is built into the same tool developers are already using (Aura), rather than offered as a heavyweight separate system. The friction of "self-host your VCS" becomes "start this daemon on a box you have." That is the intended bet.

Relationship to Other Aura Concepts

Mothership is the piece of Aura that handles team-level state. It is intentionally not the piece that handles AST analysis, intent logging, or single-developer history — those are the local Aura primitives and they work fine without a Mothership.

In practice this means:

A solo developer uses Aura without a Mothership and gets semantic versioning for themselves.
A small team starts a Mothership when they need function-level sync and impact alerts.
An AI-augmented team adds Sentinel on top to coordinate human and AI activity on the same repo.

Mothership is additive. It does not change how your individual aura commands behave; it extends them to a team.