Installing a package should never run its code.
Pin. The nestr CLI is built to pin every dependency by its BLAKE3 content hash and re-check it on install.
Verify. Pellets are designed to be signed by a verified identity and recorded in a transparency log; neither is switched on for the hosted registry yet.
Contain. The CLI is built never to run package code while installing; hooks run only when you invoke them and consent, inside a Linux (x86-64) sandbox.
None of this is available to customers yet: the CLI has no install path. See what runs today.
Nestr is designed so that an adversary who fully compromises a package maintainer cannot run code on your machine. That is a design goal of the Pellets specification, not yet a proven guarantee. See the known limitations.
What runs today
The Pellets specification describes the whole system. This is the part a customer can use today, and what is not running yet.
| What | Status today |
|---|---|
| Nest dashboard account: sign up with a verified email address and get a personal organisation | Available, free |
| Refusal explanations: every refusal explained from a fixed catalogue mapped to the specification's requirement IDs | Available, free. In the dashboard's Explain page |
| The same verification rules on every plan; verification is never capped | In force on every plan |
| Security record: running totals of extractions verified on the hosted engine | Available |
| Namespace claim on registry.nestr.tools by DNS TXT proof | Available. An operator countersigns each claim; publishing is not open yet |
| Organisation invites | Early Access. Checkout runs in a sandbox, so no real money moves yet |
| The nestr CLI: pinning, install-time verification and sandboxed hooks | Not yet available. Private, with no install path, including for Early Access |
Not running yet: signing and the transparency log on the hosted registry, and the dashboard's diff, provenance and quarantine screens, which show labelled sample data. See the known limitations or create a free account.
How Nestr is designed
Every part of Nestr is built for one job: verifying and reviewing a dependency change before it reaches your machine. Most of it is not yet available to customers; see the known limitations.
Pellets: content-addressed packages, built to be signed
A pellet is identified by the BLAKE3 hash of its contents. Signing with a verified identity and transparency logging are specified but not yet running in production. The nestr CLI, which is not yet available to customers, checks hash, signature and build provenance on install and never runs package code while installing. Log-inclusion checks are not wired yet.
- Same name and version, same artifact
- No code runs at install time
- Lockfile hashes and signatures re-checked on install
One goal across the platform
Pellets carry the trust. The Nest is where you review changes. Perch shows the signals. Each part serves one design goal: a maintainer whose account is fully compromised should not be able to run code on your machine. The Security page lists what is and is not met today.
- Same verification on every plan
- Hosted dashboard; hosted registry read-only
- Known limitations published
Pricing for monorepo operators
Verification is identical on every plan. You pay per organisation for team invites and security-record history. The nestr CLI is private for now and has no install path yet, including for Early Access.
Billing is monthly; annual billing is not offered yet. Payments currently run in a sandbox, so no real money moves yet.
Community
Free, for evaluating the Nest dashboard: the same verification rules as paid plans and a read view of registry namespaces.
per organisation / month, excl. VAT
- Verification rules identical to paid plans; quarantine, provenance and diff screens are previews with sample data
- Dashboard and a read view of registry namespaces
- One member: the owner
- 50 hosted compressions and 50 hosted operations a month (on the shared demo workspace)
- Security record: running totals of extractions verified on the hosted engine
Verification is never capped. Inviting your team needs Early Access. The open-source nestr CLI and self-hosting are planned for later.
Early Access
A design-partner seat: for monorepo teams who want team access to the Nest dashboard and early influence on Nestr, while it is pre-GA.
per organisation / month, excl. VAT
- Organisation invites
- Security-record history (90 days) with JSON export
- Monthly call with the founder
- Namespace claim by DNS proof (operator-countersigned); hosting and publishing when shipped
- Dashboard review screens (diffs, provenance, quarantine): sample-data preview; live when shipped
- nestr CLI access when shipped
- Email support, 48-hour response, when shipped
- Price locked for 12 months, when shipped
- Fair use: up to 3 namespaces and 25 members
- Known limitations disclosed
When shipped, the 12-month lock covers price, not scope. In return we ask for a monthly feedback call.
Enterprise
For organisations that need contractual terms, with SSO and a self-hosted transparency log planned.
- Everything in Early Access
- Single sign-on (planned)
- Negotiated service levels
- Self-hosted transparency log (planned)
- Prices in US dollars, excluding VAT.
- 30-day refund policy.
- Paying never changes verification: a lapsed subscription removes hosted features only, never verification trust.
- See the Terms and known limitations.
Where we're headed
No dates: each item is an open row in the known limitations.
Now
Hook identity
Run hooks as an unprivileged user, never as the installer or root
Default-deny syscall filter
Replace the current deny-list, as PEL-SBX-002 requires
Next
Namespace authority
Remove the stub allowlist; finish email, passkey and OIDC proofs
Transparency-log witnesses
Independent witness co-signatures on the hosted registry
Quarantine actions
Wire the dashboard quarantine queue to the backend
Later
Community tier
Open-source nestr CLI and self-hosting docs
Live payments
Move checkout out of sandbox
General availability
GA pricing once the adversary tests pass
Enterprise SSO
Single sign-on for Enterprise organisations
Alex
Founder, Nestr
I went from designing spacecraft systems to shipping digital products. That sounds like a big leap, but the core problem is the same: managing complexity across distributed systems where failure isn't an option.
Nestr exists because of supply-chain worms like Shai-Hulud. When one stolen maintainer account can push a package that runs code on every machine that installs it, detection after the fact is not enough. I wanted package distribution where a compromised maintainer cannot run code on an installer's machine at all: pinned by content, signed by a verified identity, logged in public, and never executed at install time.
So I built Nestr, with Olly as its mascot. Named the signed bundles pellets because that's what owls produce. The monitoring stack became his perch. The whole platform is a nest. That goal is written down as a specification, and the Security page says plainly which parts we do not meet yet.
This isn't a VC-backed rocketship. It's one person and one owl, building something useful, in public, one commit at a time. If that resonates — I'd love to have you along for the ride.
High energy, always learning, constantly building.
Founder journal
What the adversary tests found, and what was fixed.
2026-10-12
Our adversary tests failed. Here is what we fixed.
The engine's adversary suite showed install could write outside the workspace and a hook granted network access shared the host network. Security review then found hooks could reach host unix sockets. All three are fixed on engine main; hook identity is still open.
# fixed: PEL-ART-003, PEL-SBX-012, PEL-SBX-001 (sockets) open: PEL-SBX-001 (identity)Start with a free dashboard account
Create a free account on the Nest dashboard. Early Access, with team invites and 90-day security-record history, is open by request to the first 10 organisations.