Platform Components: Engine, Registry, Web, Landing, Olly, Perch

ELI5

Nestr is a system for installing other people’s code without ever running it by surprise. The engine checks each package (a Pellet) before unpacking it, the registry records every published Pellet in a public ledger, the web dashboard shows what was verified or refused, and an owl named Olly answers questions about the rules. The old description (a cache that vacuum-seals node_modules) is retired.

Technical Deep Dive

Source: nestr-tools docs/north-star/intent.md:16-39, railway.json, CLAUDE.md:40-53 @b8f0585; nestr-tools/engine railway.toml, internal/server/rest.go:127-170 @e9180e4; nestr-tools/pellets-registry railway.toml, cmd/registry/main.go:60-240 @5807213; nestr-tools/web package.json @6f42cca; live response headers for nestr.tools, app.nestr.tools and registry.nestr.tools, read 2026-10-25.

The load-bearing claim (intent.md:22): an adversary who fully compromises a Pellets-namespace maintainer cannot run code on a downstream installer’s machine. Everything else serves it.

flowchart LR
  DEV["installer: nestr CLI"] -- "verify before extract" --> ENG["engine library"]
  ENG -- "fetch pellets, log proofs" --> REG["pellets-registry on Railway"]
  REG -- "Rekor v1 entries" --> LOG["transparency log"]
  WIT["C2SP witnesses"] -- "cosign checkpoints" --> REG
  WEB["web on Vercel"] -- "JWT EdDSA, aud nestr-engine" --> SRV["engine serve on Railway"]
  WEB -- "toll.checkout, sandbox" --> TOLL["null0-toll"]
  P["perch, pre-production"] -. "scrape" .-> REG

Live versus not

flowchart TD
  LIVE["Live 2026-10-25"] --> L1["engine serve, Railway"]
  LIVE --> L2["pellets-registry, Railway, translog tree_size 0"]
  LIVE --> L3["web and landing, Vercel"]
  NOTYET["Not available to customers"] --> N1["CLI: private, no release, no install path"]
  NOTYET --> N2["signing and witnessed log on the hosted registry"]
  NOTYET --> N3["perch: pre-production"]
  NOTYET --> N4["live payments: sandbox only"]

The landing page states the same split: the CLI “has no install path”, and signing and the transparency log are “not switched on for the hosted registry yet” (nestr.tools, read 2026-10-25). The registry’s own /metrics showed pellets_registry_translog_tree_size 0 and witness_cosignatures 0.

Key Terms

• Pellet → a content-addressed, signed package in a framed wire format (nestr-002).
• verify before extract → the engine’s gate: no signature, provenance or log check, no extraction.
• Phase 12 → the launch-to-revenue phase opened 2026-10-12; Phase 13 holds the deferrals.

Q&A

Q: What single claim does every nestr component serve? A: That an adversary who fully compromises a Pellets-namespace maintainer cannot run code on a downstream installer’s machine (intent.md:22).

Q: Which components are live, where, and which is pre-production? A: engine serve and pellets-registry on Railway, web and the landing site on Vercel, Olly on Railway per railway.json. Perch is pre-production. The CLI exists in code but has no public install path.

Q: Which component verifies pellets before extraction, and which one logs them? A: The engine verifies (signature, provenance, log inclusion, policy) before extraction; the pellets-registry submits entries to the transparency log and requires at least two witness cosignatures when the witnessed log is configured.

Examples

A prospect asks “is this a faster npm install?” No: intent.md:28 says the audience is operators who need auditable package distribution, and speed is a side effect of content addressing, not the point. Point them to the landing page’s “What runs today” table rather than the spec.