Most code forges put repositories, accounts, issues, pull requests, and project governance behind one operator’s boundary. The Tangled federated code forge proposes a different arrangement: developers can host repositories and associated collaboration data on independently operated servers while continuing to work with people elsewhere in the network. It is an ambitious answer to a practical question—can a code forge distribute infrastructure control without breaking the collaborative workflows developers expect?
The short answer is that Tangled’s announced architecture is designed to support cross-server collaboration. Git remains responsible for source history and transfer, independently hosted servers provide repository storage, and the AT Protocol contributes network-level identity and discovery functions. Tangled also says issues and pull requests are stored alongside repository code rather than existing only inside a central platform database. Those design choices are meaningful, but they do not eliminate operational questions involving synchronization, permissions, moderation, backups, outages, or long-term compatibility.
What is Tangled’s federated code forge?
Tangled is a code collaboration service built around Git, federation, and the AT Protocol. Its architecture separates the place where a repository is hosted from the broader experience of discovering projects and collaborating with developers across the network.
In Tangled’s terminology, a repository-hosting server is called a knot. A knot can be operated by Tangled, an organization, a community, or an individual. Instead of requiring every project to reside on infrastructure controlled by one company, developers may choose a knot that fits their requirements or run one themselves.
Federation is what is intended to connect those independently operated parts. A developer using one service instance should not necessarily have to move to the same server as a project before participating. The aim is a shared collaboration network made from multiple administrative domains, not a collection of isolated Git servers.
This is more than ordinary repository mirroring. A mirror can copy Git objects between locations, but it does not automatically create shared identities, issue discussions, review workflows, notifications, or permissions. Tangled’s proposed model attempts to provide that wider forge experience across hosting boundaries.
How the architecture fits together
Git remains the source-code transport
At the foundation, repositories are still Git repositories. Developers retain familiar concepts such as commits, branches, remotes, pushes, and fetches. That matters because Tangled is not proposing a replacement version-control system that requires teams to abandon existing histories or learn a new commit model.
Git already supports multiple remotes and distributed copies, but conventional hosted forges add a centralized application layer around it. Tangled rearranges that layer. A knot stores and serves repositories, while the federated network helps people find projects and interact across server boundaries.
Issues and pull requests live beside the repository
One of Tangled’s most notable design claims is that issues and pull requests are stored alongside repository code. In a traditional forge, a Git clone normally contains the commit history but not the platform database holding tickets, reviews, labels, or discussion threads. Losing access to that platform can therefore mean losing important project context even when the source code survives elsewhere.
Tangled’s model is intended to keep collaboration records closer to the repository’s hosting layer. This could make it easier for an operator to back up project code and forge activity as a related set. However, developers should not infer that every standard Git client automatically clones a complete, human-readable issue and review archive. The exact storage representation, replication behavior, export process, and restoration procedure remain important implementation details to verify.
Federation connects independently operated knots
A self-hosted code forge is often useful inside one organization, but it can become an island. Federation is intended to let a knot participate in a wider network so that developers can collaborate without placing every repository under the same operator.
That arrangement introduces at least three distinct roles: the developer’s identity, the server holding a repository, and the network services used to discover or present activity. Keeping those roles conceptually separate helps explain why an outage or policy decision in one part of the system may not have the same effect as a total centralized-platform outage. It does not mean every component is redundant, however.
Where the AT Protocol enters the picture
The AT Protocol, also used by the Bluesky ecosystem, provides decentralized identity and data-networking primitives that Tangled uses for its federated layer. Tangled’s design applies those primitives to code-hosting identities, repository discovery, and collaboration activity rather than attempting to transfer Git objects through the social protocol itself.
In plain language, Git handles code history, knots host repositories and related project data, and the AT Protocol helps connect users and information across the service. Developers should consult the official Tangled documentation for the current division of responsibilities, because protocol records, indexing behavior, and server software can evolve independently.
What developers could gain from federated Git hosting
More control over infrastructure
Running a knot may let a team choose its hosting provider, storage location, upgrade schedule, backup policy, and operational controls. Community projects could similarly use infrastructure funded and governed by their own members.
That control is not the same as complete independence. A self-hosted instance may still rely on DNS providers, identity services, network indexes, certificate authorities, or upstream software maintenance. Teams should map those dependencies rather than treating “self-hosted” as a guarantee that no outside service matters.
Potentially easier movement between operators
Separating identity from a single forge operator and keeping project activity near the repository could improve portability in principle. A project might be able to change its hosting arrangement without rebuilding its entire community presence from scratch.
Portability must nevertheless be tested, not assumed. A credible migration procedure should preserve Git references, issues, pull requests, comments, authorship, timestamps, permissions, and stable links. It should also document how followers, indexes, and remote contributors learn that a repository has moved.
Community-run hosting
Federation creates room for language communities, open-source foundations, universities, and regional groups to operate knots under their own rules. One community could optimize for long-term archival, while another might prioritize low-cost contribution workflows or local governance.
The tradeoff is operational diversity. Different knots may have different uptime, moderation standards, storage limits, update schedules, and security practices. A network with more operators can reduce dependence on one administrator, but it can also create uneven service quality.
Practical questions teams should investigate
How are repositories mirrored and synchronized?
Teams need to know whether a second knot can act as a live mirror, a delayed backup, or only a conventional Git remote. They should test what happens when two copies receive changes during a network partition and how non-branch references or collaboration records are reconciled.
- Which Git refs and repository metadata are replicated?
- Are issues and pull requests included in mirrors?
- Can maintainers promote a mirror after the primary knot fails?
- How are stale, conflicting, or partially transferred records detected?
Federation does not automatically mean multi-primary replication. A repository can be visible across a network while still depending on one authoritative knot for writes.
How do identity and permissions work across servers?
Cross-server identity is useful only when authorization remains understandable. Maintainers should verify how a Tangled identity maps to repository roles, how keys or credentials are rotated, and how quickly revoked access takes effect.
Teams should also ask whether permissions are evaluated by the repository’s knot, cached elsewhere, or represented in network records. A remote identity may be recognizable without being trusted to write to a project. Identity, authentication, and authorization are related but separate concerns.
Who handles moderation and abuse?
A federated forge needs policies for spam, malicious repositories, harassment, impersonation, and abusive issues or pull requests. Local operators may be able to block users or content, but disagreements between servers are inevitable. Developers should understand who can remove material from a knot, who can hide it from an interface or index, and whether other servers may continue displaying copies.
Federation does not automatically guarantee censorship resistance. It can distribute control, but server operators, hosting companies, domain registrars, network indexes, and legal jurisdictions can still affect availability.
What happens when a knot goes offline?
Existing local Git clones may preserve source history, but contributors could still lose the ability to push, open issues, update pull requests, or retrieve collaboration data from the unavailable knot. Discovery pages may retain cached metadata without having a writable destination behind them.
A production plan should identify a recovery target, backup frequency, restore procedure, DNS or addressing changes, and the process for declaring a replacement authoritative. Teams should rehearse recovery rather than assuming another server can seamlessly take over.
Are backups complete and restorable?
A useful backup must include more than the default branch. It should cover all required Git objects, issues, pull requests, comments, repository settings, access-control information, and any signing or service keys needed for restoration. Administrators should confirm whether Tangled provides a supported export format and whether backups can be restored to a different knot implementation or only to the same software version.
Important limits and unfinished features
As reflected in Tangled’s announcement and documentation available through October 2026, private repositories and a command-line interface were listed as upcoming features. Developers should not plan around either capability until the project’s current release notes and deployed service confirm availability. Git itself has command-line tools, of course, but that is different from a dedicated Tangled CLI for forge operations.
Other questions require practical evidence. It is not yet safe to assume seamless migration between every knot, conflict-free synchronization during outages, uniform moderation, or compatibility with unrelated forge software. Federation within Tangled also does not automatically create interoperability with GitHub, GitLab, Forgejo, ActivityPub services, or every AT Protocol application.
Privacy is likewise a separate matter. Self-hosting can give an operator more control over storage, but public federation may distribute metadata to indexes, clients, or other services. Teams handling confidential code should wait for documented private-repository behavior and complete a security review before uploading sensitive material.
Who should experiment with Tangled?
The system is most immediately interesting to open-source maintainers, federated-web developers, self-hosting enthusiasts, research groups, and communities willing to test new infrastructure. These users can explore how a knot behaves, contribute operational feedback, and evaluate whether repository-linked collaboration data improves project continuity.
Production teams should be more methodical. Before relying on the Tangled federated code forge, verify private-repository status, authentication controls, backup completeness, migration tooling, outage recovery, moderation options, update practices, and the stability of any APIs or data formats. Review the latest status on the official Tangled Blog, then reproduce the critical workflows in a disposable environment.
Tangled’s architecture offers a thoughtful alternative to the assumption that collaboration must live inside one provider’s database. Its real value will depend on whether independent operators can deliver reliable hosting while preserving a coherent developer experience across the network. That outcome requires testing, documentation, and operational maturity—not federation alone.
Frequently asked questions
Can developers collaborate across different Tangled servers?
That is the intended purpose of Tangled’s federated architecture. Independently operated knots can participate in a shared network, allowing developers to discover repositories and collaborate across hosting boundaries. Exact workflows and limitations should be tested against the current release.
Does cloning a Tangled repository automatically download every issue and pull request?
Not necessarily. Tangled says issues and pull requests are stored alongside repository code, but that does not mean a normal Git clone automatically produces a complete collaboration archive. Verify the documented storage, export, mirroring, and restoration procedures.
Does federation guarantee that a repository will remain online?
No. Availability depends on the knot hosting the repository, its backups, mirrors, network dependencies, and recovery plan. Local Git clones can preserve source history, but they may not preserve every collaboration feature or provide a writable replacement server.
Can teams use Tangled for private production repositories?
Private repositories were identified as an upcoming feature in Tangled’s published plans, so teams should not assume they are available or production-ready. Confirm current feature status and evaluate access controls before placing confidential code on the service.
