Sources

What a source is, what we do with it, and how to keep the list manageable.

A source is the unit you track. In practice that almost always means a GitHub repository, but it can also be any release-notes page that has a stable parser. One source produces a stream of releases, and each release goes through diff analysis and gets a risk score. The source itself also gets a trust score: a separate 0–100 number that answers "how comfortable should I be depending on this project at all?"

The lifecycle of a source #

  1. Add. You paste a URL, we record it, and queue an initial sync. For a source with no stable parser that nobody else tracks yet, that first sync's AI work counts toward your fair-use allowance. See Adding a source.
  2. Backfill. We fetch the most recent few releases (the cap is small by default to keep AI cost predictable) and run them through diff analysis.
  3. Poll. We check the source for new releases on an adaptive cadence: actively-releasing sources are polled about once an hour, while sources that have been quiet for a while are checked progressively less often to stay efficient, but never less than once a day, so nothing falls more than a day behind. As soon as a new release shows up, the source snaps back to the fast hourly cadence. New releases are summarized and risk-scored automatically.
  4. Alert. If you have a lockfile that references this source, a high-risk update fires an alert and shows up in the pulse feed.

You can manually trigger a sync from any source's detail page if you want to pull in something just-published without waiting for the next scheduled poll.

In the dashboard and explorer, each source shows a small icon to make a long list easier to scan: a GitHub repo uses its owner's public avatar (github.com/<owner>.png), a VS Code Marketplace extension uses its published icon, and any other web source uses its site favicon. When an icon can't be loaded we fall back to the source's initial. The icon is loaded by your browser straight from the source's own platform. Only the owner name, extension id, or hostname appears in the image URL, the referrer is suppressed, and no account data is sent. See Privacy for the detail.

When a source was discovered from a lockfile, its dashboard card and detail page show a Used in row listing the lockfile(s), labeled by the connected repo (owner/name), that the dependency lives in. On the detail page the same Used in links repeat inside each release card, so when you're reading a specific release you can jump straight to the repos it affects without scrolling back to the header. Each entry links to the lockfile's detail page, and GitHub-connected lockfiles also get a shortcut straight to the repo on GitHub. If you sync lockfiles from several repos, this is the fast path from "this dependency shipped a risky update" to "…and here are my repos that need a look." Sources you added manually or via starred-repo sync have no originating lockfile, so they simply omit the row.

On a source's detail page, each release card carries its colour-coded risk score and a High signal tag when the release ships breaking changes, security updates, or a High-band score, so a noisy project's handful of releases that actually matter are easy to spot.

Source URL shapes we accept #

  • GitHub repository: https://github.com/<owner>/<repo>. We use the repo's tagged releases.
  • VS Code extension: a https://marketplace.visualstudio.com/items?itemName=<publisher>.<extension> Marketplace URL or an https://open-vsx.org/extension/<namespace>/<name> Open VSX URL. We track the extension's published version history.
  • Static release-notes page for vendors with a stable parser, e.g. Google Ads. See the parser catalog for the current list.
  • Anything else: we route it through the AI fallback parser. This works well for well-structured changelog pages and poorly for paginated or JS-rendered pages. See Parser types for the trade-offs.

Limits #

The Hobbyist tier caps you at 1,000 sources (sized to fully cover one project's lockfile); paid tiers are unlimited. If you're hitting the cap, the Lockfiles workflow is usually the right answer: track what's actually in your dependency tree, not every library you've ever used.

Removing or pausing a source #

Sources can be deactivated (we stop polling but keep the history) or deleted entirely. Both live on the source detail page. Deactivating a source frees up a slot on the Hobbyist tier without losing the analysis history.