Privacy.

Your manifests and lockfiles, the folders you point Monogrove at, the workspace paths it walks, your configuration, and the update plans you review are all held locally. None of them are uploaded anywhere. There is no Monogrove account, no Monogrove server that holds your data, and nothing to sync.

To tell you whether a dependency is behind, Monogrove asks a registry which versions of that package exist. Public packages are requested from npm; packages your .npmrc routes elsewhere are requested from that registry instead. What is sent is the package name — not the project it came from, not the version you have installed, not the path on disk.

If your configuration supplies a token for a registry, that token is attached only to requests to that same registry. If the registry address isn't a secure one, Monogrove refuses to send the credential at all and surfaces an error rather than quietly falling back to sending it in the clear.

in the source · internal/registry/registry.go · Client.FetchMany

Advisories come from OSV.dev, which has to be asked by package name. Monogrove only asks about packages it can prove sit inside the public npm trust boundary: the package must resolve to https://registry.npmjs.org, and there must be no configured credential for it.

Anything authenticated, private, or served by a custom registry is withheld — those names are never sent to OSV. Monogrove reports them to you as skipped rather than checking them anyway, so a private package name can't leak through the advisory path.

in the source · internal/registry/registry.go · Client.AdvisoryLookupSkipReason (eligibility) · internal/advisory/advisory.go · Client.FetchMany (query)

The app checks monogrove.com/appcast.xml for new releases. That request carries the version of the app that's running and how it was installed — brew, dmg, or dev — so release adoption can be counted in aggregate from the web server's access log.

Monogrove adds no persistent per-install identifier to that request. The version and install-source values are shared by every install that matches them, so neither value is unique to you. That is a statement about what Monogrove puts in the request — not about what the request reveals in transit; see what this can't cover below.

in the source · internal/appcast/appcast.go:81–104

Updates are applied by running your own package manager — pnpm, npm, yarn, or bun — as a local subprocess on your Mac. The complete plan renders first, and nothing runs until you confirm it. Those commands talk to whatever registry your project is already configured to use; they don't route through Monogrove.

monogrove.com carries no analytics, no advertising trackers, and no third-party scripts. The screenshots and icon are first-party assets served from this origin, and the typography uses fonts already installed on your system rather than any webfont — so loading the page makes no third-party request at all.

Monogrove controls what it sends. It can't make a network connection invisible. When it asks npm, your configured registry, OSV or monogrove.com for something, those services — and anything sitting in the network path — can observe the ordinary metadata of an HTTPS request: your IP address, when it happened, where it went, and roughly how big it was.

That is true of any software that talks to the internet, and no application-level choice removes it. What Monogrove can decide is which requests are worth making at all, and what goes inside them — which is what the sections above describe.