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
Hosted Deployment Design Boundary
A future service could target multiple operating environments only after the repository protocol and security boundary exist.
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 does not ship a deployable repository server, hosted control plane, official server image, production Compose stack, supported Helm chart, operator, managed database schema, or cloud deployment. Historical deployment files do not make the quarantined backend a product.
Possible design targets
- One supported server architecture with explicit state ownership and recovery semantics.
- Reproducible artifacts for selected environments rather than claims of universal deployment support.
- Documented observability, backup, upgrade, rollback, security, and capacity contracts.
Prerequisites before implementation claims
- A complete authenticated remote repository protocol and maintained server implementation.
- Threat modeling, tenant isolation, secret management, migrations, and disaster-recovery tests.
- Published artifacts, provenance, release ownership, compatibility policy, and production evidence.
What can be evaluated today
- Install or build the local CLI for an evaluation on one machine.
- Build the checked-in CLI Dockerfile from source only as a local packaging experiment; no official image is published.
- Keep independent backups and do not treat deployment drafts as runnable service instructions.