Pillar
Native Git repositories
The DevKosher Git server speaks protocol v2 because it wrote it. There is no upstream binary in the critical path.
Sovereign forge
The forge that owns its protocols
DevKosher does not assemble third-party software behind a theme. It implements the protocols: the Git server speaks protocol v2 because it wrote it, the registry speaks OCI Distribution v1.1 because it wrote it.
The estate measured on the forge
The only quantities published on this site are the ones that were measured. They carry their date. None is rounded to look good, none is projected.
2,704
projects
103
groups
115.42 GiB
of repositories
28.64 GiB
of large files (LFS)
69.02 GiB
of packages
Four pillars, one platform
One data model, one authorisation model, one clock. The user sees one platform, and the operator runs one.
Pillar
Continuous integration
Our own graph engine and scheduler. No plugin, no gateway to a third-party runner.
Pillar
Artifacts
An image registry that speaks OCI Distribution v1.1, and seven package registries that each speak their own protocol.
Pillar
Supply-chain assurance
The chain becomes verifiable end to end because the platform holds both ends.
A platform, not an integration
A component is native if and only if the platform can serve the protocol with the third-party process stopped, if a conformance suite runs an unmodified reference client — git, oras, npm, docker — against our implementation, and if the verdict of that suite is a derived quantity. A component that fails any of the three is an integration, and declares itself as one.
Three states, never two
A DevKosher surface tells three situations apart and renders them differently: populated, empty — the registry was read and holds nothing — and unreachable, declared with its reason and the time of measurement. An unreachable registry is never replaced by a sample.