Design archive — not shipped
This page describes a future or historical network, API, P2P, or deployment surface. The current product is a local alpha; there is no working network transfer, hosted server, public API/SDK, or deployable service.
Design Archive
Self-Hosting Design Boundary
Running a utility process is not equivalent to operating a supported repository service.
Design, not a shipped service
The current product is a local alpha CLI and library. There is no hosted Dits service, complete repository remote, public API or SDK, managed webhook system, official server image, or supported production deployment. The items below are conditional design targets, not setup instructions or commitments.
Status
Dits has no deployable self-hosted control plane, user service, authenticated remote, database schema, worker system, admin UI, upgrade contract, or server backup procedure. The quarantined backend crates and historical diagrams are not active product components.
Possible design targets
- A single documented service topology with secure defaults and explicit state ownership.
- Local operator control over identity, storage, retention, backups, upgrades, and observability.
- Repeatable installation and recovery procedures proven against released artifacts.
Prerequisites before implementation claims
- A maintained authenticated server and complete repository-exchange protocol.
- Authorization, audit, secret lifecycle, abuse controls, migrations, and disaster recovery.
- Published packages, support matrix, threat model, operational runbooks, and conformance tests.
What can be evaluated today
- Keep repositories local and copy them with local-filesystem clone or independently managed backup tools.
- Use dits serve only as an unauthenticated object utility on a trusted or isolated network behind a firewall.
- Never expose dits serve to the public Internet or treat it as a complete remote repository.