Tangled announced a forge overhaul on October 30 that moves issues and pull requests onto the server holding a project's code, storing them as Git objects. For maintainers weighing where to host a project, the change addresses a practical problem: keeping the discussion and review history under the same control as the source.
The announcement describes the storage design alongside a redesigned interface and new organization accounts. Its v1.20.0 upgrade guide confirms the data move and lists changes self-hosters must make. We reviewed those primary documents, but haven't run a migration or tested the new interface. Portability is the design's stated purpose, rather than a result we've independently demonstrated.
What now lives beside the code
Tangled calls its Git repository server a knot. In the new implementation, issues, pull requests, comments, reactions and labels live there as collaborative objects, or COBs. Each COB is a chain of Git objects inside the repository, according to the release announcement. Collaborator information, knot membership and the blocklist use the same approach.
The versioned migration instructions make the previous location explicit: issues, pull requests, comments, labels and collaborator grants move from each author's personal data server, or PDS, into the knot. That gives maintainers a specific architectural change to assess when considering Tangled's portability claim. Hosting the code and hosting its working history become more closely connected.
Authorship still crosses that boundary. Tangled says that creating or editing a record through the web app also writes an attestation to the author's PDS. That record points to the exact version on the knot and the corresponding COB change. The mechanism is intended to let the two sides verify the record's authorship. The announcement alone doesn't establish how every client handles missing or conflicting attestations.
Self-hosting can cover only part of the service. Tangled's hosting documentation separates repository storage from CI runners, the browser client and the indexer. A maintainer can therefore choose which services to operate, rather than taking on the whole forge at once.
The upgrade changes storage and proxy configuration
Existing operators need to read the v1.20.0 instructions before deploying. That section assumes the Rust-based knot is already running. Operators still using the Go implementation are directed to a separate migration guide.
An operator contact email is now mandatory. So is an LFS storage path, because the knot now holds AT Protocol record attachments. The guide recommends placing that storage beside the repository directory. Operators who already configured LFS need no change to that setting.
The event-stream endpoint also moves from /events to /xrpc/com.atproto.sync.subscribeRepos, requiring a reverse-proxy update. Together, those requirements show why this release needs more preparation than a binary replacement: it changes where project data is kept and how updates reach the indexer.
Tangled says private repositories, a CLI and language SDKs are next in a launch spread across several weeks. Those remain announced follow-ups. For maintainers evaluating this release, the useful next evidence will be migrations that demonstrate whether discussion history and attachments remain intact when a project changes hosts, with authorship still verifiable under the documented attestation scheme.