Self-hosted forge · build fleet · package mirror
Ship software nobody else can switch off.
LibWorld hosts your repositories, builds them on machines you own, and mirrors every package those builds pull — so the whole chain from source to production runs inside your network, on hardware nobody can take away from you.
- Offline-first
- A bad day at npm is not a bad day for you.
- Hermetic
- Builds resolve through your own mirror, so every dependency is catalogued as it is used.
- 13 ecosystems
- One service, one endpoint, a real backend for each.
- Yours
- Your metal, your repos, your copies. No account, no vendor, nothing to sign up for.
Not just a mirror — a forge and a build fleet
Push to a repository LibWorld hosts and the push is what queues the build. The coordinator reads the recipe out of the repo, picks a runner whose advertised labels cover what the target needs, and hands over the work. Runners poll outward, so a build host needs no inbound port at all.
What comes back is a fleet you can actually see: which machines are
online, what each one is able to build, and which phones and tablets
are plugged into them right now. A ? marks
a fact that was declared rather than
measured — a device that says it is a tablet and a device
observed to be one are different claims, and collapsing them is how
an inventory quietly stops being true.
And production is reached by promotion, never by landing on it. A deploy target names the staging target it is promoted from, and the coordinator refuses to queue it unless the exact workspace staging verified is the one being installed.
$ world runners
● astro nvenc
● didi android expo device node
● elroy-build sandbox publish android expo node
● elroy-deploy deploy ansible ci node → building #660
● jane ios macos simulator device node
● rudi cpp prod
● sentro device node
$ world devices
● R4XK07PMDQ91TZ android phone? Pixel_9_Pro @sentro
● HT4Q19X83006 android phone? Pixel_XL @didi
● 00008120-0014… ios phone iPhone 12 Pro Max @jane
● c1b7d40f92ae… ios tablet iPad (6th gen) @janeEvery runner advertises what it can build, and every device says which host it is attached to — so a target picks the machine it needs instead of you naming one.
Thirteen ecosystems, one endpoint
Each of these is a real implementation of somebody else's protocol, with its own rules about what may be cached and what has to be asked again. Open one to see what it stores, what it revalidates, and what has cost us real time.
Change a URL. That is the integration.
A mirror is only worth having if the tools you already use can talk to it without being modified. Every LibWorld backend speaks its ecosystem's real protocol — the PEP 503 index pip expects, the packuments npm expects, and the Registry V2 API docker expects.
So pointing a build at it is a config line, not a migration. The first time you ask for something, LibWorld fetches it from upstream, hands it to you, and keeps a copy. Every time after that, the copy is what you get — which is why the second build is faster and why the hundredth still works with the network unplugged.
# npm
registry=http://mirror.internal:10220/npm/
# pip
index-url = http://mirror.internal:10220/pip/simple/
trusted-host = mirror.internal
# apt
deb http://mirror.internal:10220/apt/ubuntu jammy mainThat is the whole client side. There is no agent to install and no SDK to adopt.
A mirror, a forge, and a build fleet — in one service
Everything here runs today — and where something is not built, this site names it rather than leaving it to be inferred.
Mirror what you depend on
Every ecosystem your builds pull from, cached on hardware you own and still answering when upstream is not.
Drop-in proxy
One config line. Every artifact it fetches is kept, and served locally next time.
A catalog you can query
What you have, what a release depended on, and when each artifact was last pulled.
Prefetch before you go dark
Warm the cache while you still have a network, as a background job you can poll.
Retention and GC
Reclaim space by age and last use, with pins and OS images protected automatically.
Boot a machine from your mirror
Mirror OS images like packages, then install a bare machine with every byte from you.
Know what you actually have
A copy is only worth keeping if you can say what it is — checked against what upstream published before it is stored, and provable again years later.
Pull audit
Who changed the mirror, and what this build actually pulled from it.
Verified against what upstream published
Checked against the digest upstream published, and refused before it is stored.
Snapshots you can replay
Freeze what the mirror holds under a name, and verify later that nothing moved.
Locked down by default
Anonymous to read, token-gated to change, and it refuses to start up unsafe.
Host it, build it, ship it
The repositories, the machines that build them, the gate production is reached through, and the clients you drive all of it from.
A build service that uses the mirrors
Build your code against your own mirror. Runners poll out, so no inbound ports.
Self-hosted git forge
Host your repos beside the mirrors, and let a push trigger the build that deploys it.
Production is reached by promotion
Production is where work arrives by having passed staging — not a host you deploy to.
What your fleet is, beside what it says it is
What your machines actually are, beside what your document says they are.
Clients for how you actually work
A CLI, a dashboard, and an Android/iOS app that watches builds and mirror health.
Everything on this page runs today — nothing here is planned, in progress, or coming soon. Every feature in detail →
One CLI, the whole supply chain
The same verbs work for every ecosystem. Warming the cache before a
flight is world prefetch whether the thing
you are warming is a wheel, a crate, or a container image.
Past the mirror, the same binary talks to the git forge and the build service — so hosting a repo, building it against the mirrors, and promoting to production the exact bytes staging verified are three commands rather than three tools.
# run the proxy/mirror in front of thirteen ecosystems
world serve
# warm the cache before you go offline
world prefetch pip requests
world prefetch maven com.google.code.gson:gson:2.10.1
world prefetch docker alpine:3.19
world git add torvalds/linux
# see what you have, and keep what matters
world ls --backend npm --limit 20
world pin cargo <blob-key>
world orphans --adopt
world gc
world audit --since 30d
# host the repo, build it, promote what staging verified
world repo create my-service
world build my-service --watch
world install my-service 42 --target deploy-prodThe mirror, the catalog, the forge, the build service, and all three clients run today. LibWorld is early, and self-hosted from end to end.
Own your dependencies before they own you.
Every build you run today is a bet on somebody else’s uptime, retention policy, and goodwill. The cheapest day to stop betting is a day when nothing is broken.