Software supply chains are too fragile.

LibWorld is three things in one service: a git forge for the repositories you own, a build fleet that runs them on your own machines, and an offline-first mirror standing in front of everything those builds depend on.

The mirror is the part with the most surface: it proxies apt, pip, npm, git, cargo, go, maven, rubygems, nuget, cocoapods, docker, file, and iso, stores everything it fetches, and serves it from inside your network. The build service is what makes that mirror complete rather than merely present — builds resolve through it, so every dependency a release actually used ends up catalogued because it was used.

The result is builds that don't depend on the public internet being up, fast, or unchanged, and a path to production that does not leave your network. Pin what matters, prefetch before you go offline, and keep a queryable record of every artifact you have.

LibWorld is a small set of C++ services. Boost and the JSON library are vendored and built from source; the rest is what a Linux host already has — libcurl, OpenSSL, libpq, and the system's own git and gpgv:

• The mirror — a Boost.Beast HTTP proxy with a backend per ecosystem, a Postgres catalog of everything mirrored, blob storage in any S3-compatible object store (the S3 client is SigV4 over libcurl, not a vendored SDK) or on local disk, retention/GC, and audit logging.
• The forge — self-hosted git repos served over smart-HTTP: clone anonymously, push with a token, browse over REST, and let a push trigger a build.
• The build service — a coordinator plus runners that poll out to it, so build hosts need no inbound ports. Builds resolve their dependencies through the mirror, which is what makes them hermetic and what gets every dependency catalogued.
• Deploys and promotion — a target declares the environment it deploys to and the staging target it is promoted from, and the coordinator refuses to queue it unless that exact workspace passed staging and the artifact being installed is that staging build's. Production is reached by promotion, not by landing on it.
• Netboot — declared OS images become generated iPXE scripts, so a machine can be installed from the mirror with every byte verified against a published checksum and, where a keyring is supplied, a GPG signature.
• The clients — a world CLI, a React control-plane dashboard, an Android/iOS app, and an MCP server so an assistant can read the fleet without being handed a shell.

It is self-hosted by design: run it on your own box, keep your own copies, owe nothing to anyone's uptime. Deployment is Ansible and systemd — host-native, no Docker required to run it.

All thirteen backends mirror end to end, against both local-disk and S3-backed storage. The catalog, prefetch, retention/GC, the artifact lifecycle, the audit log, token auth, the forge, the build service, the promotion gate that guards production, upstream-attested verification, snapshots, and all four clients are working today.

The last two of those shipped on 2026-09-02, and this paragraph said the opposite until they did: package signature verification and snapshots were the two things named here as not built. A package is now checked against the digest upstream itself published — and for apt, against the whole GPG-signed chain from the archive key down to the individual .deb — before its bytes are stored; a snapshot freezes what the mirror holds under a name, protects it from collection, and can be re-verified byte for byte later. OS images were the exception all along: the iso backend verifies a published checksum and, where a source declares a keyring, a GPG signature — with gpgv against exactly that keyring, never the ambient one — and refuses at load if a source claims a signature it has no key for.

It's early software, and it runs on hardware you control.