Installing a Package Should Never Run Its Code

nestr beginner 3 min read

What this means for you

Nestr is supply-chain security for monorepo dependencies: packages (Pellets) pinned by content hash, built to be signed and recorded in a public log, and installed without ever running their code. It is pre-release. The 2026-05 positioning (“compress what you install, watch what you run, code beside you”) is retired; compression is a side effect, not the product. Sources: nestr-tools docs/north-star/intent.md:16-28 @b8f0585; landing src/lib/metadata.ts:20, src/components/sections/Hero.tsx:89-120 @cb59f69; nestr.tools, read 2026-10-25.

The pitch

“Installing a package should never run its code.” The design goal: an attacker who fully takes over a package maintainer still cannot run code on your machine. The site says plainly that this is a goal of the specification, not yet a proven guarantee, and that the CLI has no install path yet.

Who it’s for

Teams who own a monorepo’s dependency supply chain and want something they can audit end to end. Not people who only want a faster install (intent.md:28).

Proof points

Hero, live: “Pin. Verify. Contain.” with a pre-release badge, “Early Access open to 10 organisations”.
Honest status on the page: signing and the transparency log are “not switched on for the hosted registry yet”; the dashboard’s diff, provenance and quarantine screens show labelled sample data.
What a customer can use today: a free dashboard account with an organisation, refusal explanations, the same verification rules on every plan, a security record, and a namespace claim by DNS TXT proof.
The owl stays as the mascot: pellets are what owls produce, the monitoring stack is the perch, the platform is the nest. The mascot names things; it is not the pitch.

mindmap
  root((Nestr))
    Pin
      BLAKE3 content hash
      lockfile re-checked
    Verify
      signed by a verified identity
      transparency log
      not yet on hosted registry
    Contain
      no code at install
      hooks only with consent
      Linux x86-64 sandbox

neighbors on the map

Platform Components: Engine, Registry, Web, Landing, Olly, Perch onboarding to nestr-tools and deciding which submodule owns a change
Not a Rocketship: One Person, One Owl, In Public answering 'why should I trust this is still around in two years'
Not a Build Orchestrator, Not a Cache answering 'how is this different from Nx or Turborepo'