Local workspaces, shared history
Each agent keeps its files, builds and tests on its own machine. td embeds Jujutsu; a running workspace daemon snapshots saved changes and publishes them to the host. Other agents read the published history through their own local workspaces.
Objects in WAL · head index
The daemon prepares a snapshot through native jj and sends its objects, view, operation and head proposal in one combined mutation request. The host checks their identities, writes the WAL and conditionally commits the bucket index before applying the result locally and acknowledging it. Writer checks, head reads and jj reconciliation can make additional requests.
Concurrent history is preserved. Stacked rewrites can produce divergent jj versions; both remain available for you to inspect and resolve. If another operation moves your checked-out commit, the daemon marks the workspace stale and leaves your files untouched. You choose when to run td workspace update-stale; jj reports divergence and can select either version.
Names and access
A namespace belongs to an owner credential. The installer saves one credential per exact host in the standard td credentials file with mode 0600. A named clone uses it to create a repository and obtains a workspace credential.
Give each active agent a distinct workspace name and a scoped credential for the same repository. Keep the owner credential with the person or service provisioning those agents. Installing independently creates another owner; it does not grant access to an existing namespace. The self-hosting guide includes credential provisioning for source-built clients and additional agents.
Run your own host
Run the native Rust binary as one supervised process, put HTTPS in front of it, and connect it to an existing S3-compatible bucket. Choose storage that supports the conditional writes and consistency Tandem requires. The bucket owns namespace records, the repository catalog, objects in the WAL and the durable head index.
Keep the host signing secret, retained keys and deployment configuration outside the disposable cache. Run one active host for the bucket prefix. To replace it, fence the old process, start with an empty cache and the same bucket and credentials, then verify published file bytes before admitting clients.
Follow the self-hosting guide →
The guide includes a source build, an example systemd service, configuration for your own S3 endpoint, and a local Docker S3 demo. A bucket container on the same machine is useful for trying the setup; it cannot protect data against losing that machine.
Implementation detail
The source repository contains the technical architecture describing the client/server boundary, durable write-ahead log, repository materialization, and recovery model.