ahhhh it works! I have an atproto PDS, knot, spindle, and hold, all driven by a repo hosted on the knot, running on container images created by the spindle and hosted on the hold. The accounts that tie it together all live on the PDS. tangled.org/cove.town/cove.town
cove.town/cove.town
tangled.orgAug 9, 2026 at 4:39 PM
cove.town/cove.town
Self-contained atproto self-hosting setup with PDS, knot, spindle, and hold
cove.town/cove.town
Self-contained atproto self-hosting setup with PDS, knot, spindle, and hold
Migrating to the new Tangled knot2 | jola.dev
Tangled is a Github alternative built on atproto. I've previously shown you how to set up the self-hosted repo server, here I go through migrating to knot2.
/atproto-crates/crates/atproto-pds at main · ngerakines.me/atproto-crates
A repository on Tangled
proposal: ingest repo records #282
`sh.tangled.repo` records are one of the last few records that need atprotation (2-way sync between appview/pds). this one is tricky because we want consistency between knot state, appview state and PDS state. the path forward is described below: - migration to did/rkey syntax universally: in several places, we utilize `did/repo-name` as a globally unique identifier for a repository, we should migrate this to `did/rkey`: * for the tangled appview: this means reworking our ACLs, routers and DB to use `did/rkey` or ATURI as a globally unique identifier for a repo * for knots: this means changing paths on disk to be `did/rkey`, allowing git ops to `host:did/rkey` , updating ACLs, and XRPC endpoints * for spindles: this means updating ACLs and XRPC endpoints - once this is done, we can define ingestion logic for all services in the network to pull sh.tangled.repo records * for the tangled appview, this should create/delete/update a repo pointer record * for knots: this should create-or-ignore/delete-or-ignore/update-or-ignore a repo on disk. migration of repos needs to be thought out here. * for spindles: as above - define edge-case behaviors: * when referring to repos by rkey, it is possible for clever users to create duplicate records with the same repo-name, appview routers must handle this ambiguity with a new interstitial page that offers a redirect, knots must return an error upon push/pull on ambiguous git URLs * the `knot` cli can introduce a command `backfill` or `sync` to bring knot state up to sync with the rest of the world (repos, collaborators, pubkeys, ACLs etc.).
Ok, continuing the series on the atproto self-hosted components that make up covetown, here's how you set up a knot and spindle for @tangled.org Caveat: they're in the process of rolling out new components, but there's a migration path, and I'll write about that too! jola.dev/posts/self-hosting-and-tangle…
Self-hosting and Tangled
jola.dev