Everything you need to know about DevUpdate.io, the news feed for your dependency stack
DevUpdate.io is a news feed for the dependencies your project relies on. Add the libraries and tools in your stack and we keep you on top of their important releases, breaking changes, and security advisories, all in one place instead of scattered across changelogs and CVE trackers. For GitHub sources we go deeper, analyzing the code diff between versions to catch undocumented breaking changes that release notes miss.
Dependabot and Renovate create PRs to update dependencies, but they don't tell you what's actually in the update. For GitHub releases we analyze the git diff between versions to detect undocumented breaking changes, function signature modifications, and behavioral changes that aren't mentioned in changelogs. We also track sources Dependabot can't, like the Google Ads API or any changelog page on the web, with AI release summaries even where a git diff isn't available. Think of us as the intelligence layer that helps you decide whether to merge those PRs.
GitHub's home feed shows release activity for repos you've starred. It's a chronological firehose: no analysis, no risk scoring, no diff inspection, and no way to filter down to what actually affects you. It also only covers GitHub repos you've starred. Dedicated release trackers like NewReleases.io and Libraries.io clean up the notifications, but they still stop at "a new version exists" without telling you what changed or how risky it is. DevUpdate.io does the opposite. For GitHub releases we read the git diff, score the risk, and flag undocumented breaking changes, and we send you a digest scoped to the dependencies in your lockfile, so you see the updates that matter instead of scrolling past the ones that don't. We also track non-GitHub sources like the Google Ads API and other release-notes pages.
Context7 feeds up-to-date library docs and code snippets to AI coding agents over MCP, so generated code uses current APIs. It answers "how do I use this library right now?" DevUpdate.io answers a different question: "is this specific update safe to merge, and what's actually in it?" One helps an AI write code against a library; the other gives you upgrade-risk intelligence for the libraries you already depend on. They're complementary, not competing.
Sign up for a free account, then add tracked sources by pasting a GitHub repo URL, the Google Ads API release notes, or any other release-notes page. We'll automatically fetch their releases and generate AI summaries; for GitHub sources we also analyze the code diff and add a risk score. You can also upload your lockfile, pick the dependencies you want to watch, and see available upgrades when one of them is trailing a newer, risk-scored release.
Yes! The free tier allows you to monitor up to 100 tracked sources. This is perfect for personal projects or evaluating the service.
The easiest way is to use our Lockfiles feature instead! Upload your lockfile (poetry.lock, package-lock.json, yarn.lock, etc.) from the Lockfiles tab in your dashboard, and we'll automatically discover source URLs and track all your project dependencies. This is much faster than manually adding sources one by one. If you prefer manual addition, you can search for packages on package registries (PyPI.org for Python, npmjs.com for JavaScript) and look for the 'Source' or 'Repository' link in the project details.
All ten of the lockfile formats we support: Python (poetry.lock, uv.lock, Pipfile.lock, requirements.txt) via PyPI, JavaScript (package-lock.json, yarn.lock, pnpm-lock.yaml) via the npm registry, Rust (Cargo.lock) via crates.io, PHP (composer.lock) via Packagist, and Go (go.sum) via direct module-path resolution. We extract package names, look up each one in the matching registry, and add the resolved GitHub repositories as tracked sources automatically.
Some packages are hosted elsewhere (GitLab, Bitbucket, Heptapod, Launchpad, internal repos) or don't publish their source repository to the registry. When we can't find a GitHub URL, we'll show you which packages couldn't be discovered in the results summary — and when we recognise the host, we name it ('Links to Heptapod, not GitHub') so you can tell an unsupported-host package apart from one that's just missing a link. You can manually add their sources later if they have GitHub mirrors or you find the URLs through other means.
No. Each repository file is tracked once. When you scan a repo, any lockfile you already track is shown as 'Already tracked' and can't be re-selected, and connecting the same repo file again is skipped instead of creating a second copy. This holds across the Scan, Browse, and Manual tabs.
The Lockfiles tab has a 'Repositories with access' panel listing every repo you've granted our GitHub App. Each has a 'Scan for lockfiles' button that opens the connect dialog already pointed at that repo and scans it immediately — no URL to paste. The same list also appears as a 'Your repositories' picker inside the connect dialog. To change which repos the App can see, use the 'Manage repository access' link, which opens GitHub's installation settings.
Free tier users can select up to 100 packages from their lockfile to discover and watch as tracked sources. Professional and Team tier users have unlimited source discovery. The selection UI will show your available slots and prevent exceeding your limit.
Every source discovered from a lockfile shows a 'Used in' row on its dashboard card and detail page, listing each lockfile it lives in — labeled by the connected repo (owner/name). On the detail page those same links also repeat inside each release card, so while reading a specific release you can jump straight to the repos it affects. Each entry links to that lockfile's detail page, and GitHub-connected lockfiles also link straight to the repo on GitHub. So when you sync lockfiles from several repos, you can jump from a risky release directly to the repos that need attention. Sources you added manually or via starred-repo sync don't have an originating lockfile, so they won't show the row.
package-lock.json (npm), yarn.lock, pnpm-lock.yaml, go.sum (Go modules), Cargo.lock (Rust), poetry.lock, uv.lock, Pipfile.lock, requirements.txt (Python), and composer.lock (PHP). Every supported format gets full automatic source discovery.
To make a long source list easier to scan, each source shows a small icon: GitHub repos use the owner's public avatar (github.com/<owner>.png), VS Code Marketplace extensions use their published icon, and other web sources use the site's own favicon. Your browser loads these images directly from the source's own platform — only the owner name, extension id, or hostname is in the image URL, the referrer is suppressed, and no account data is sent. If an icon can't be loaded, we fall back to the source's initial. See our Privacy doc for details.
Diff-First Analysis is our core differentiator. Instead of just summarizing release notes, we fetch the actual git diff between release tags and analyze the code changes. This lets us detect things like function signature changes, removed exports, type modifications, and behavioral changes that maintainers often forget to document. We then compare what the changelog says versus what the code actually shows.
Each release gets a 0-100 risk score based on multiple factors: code churn (lines changed), number of files modified, documented breaking changes, undocumented changes we detected in the diff, and security implications. Scores 70+ are considered high risk and warrant careful review before updating. On the Pulse feed and every release card the score shows as a colour-coded badge — teal for Low (0-39), amber for Medium (40-69), coral for High (70+) — and releases with breaking changes, security updates, or a High-band score also get a 'High signal' tag so the relevant releases stand out from routine ones.
These are modifications we detect in the code diff that aren't mentioned in the release notes. For example, if a changelog says 'minor bug fixes' but we see a function signature changed from (a, b) to (a, b, c), we flag that as an undocumented change. This is critical because these silent breaks often cause production issues.
You can upload your lockfile (package-lock.json, yarn.lock, go.sum, etc.) so we know your exact dependency versions. Once monitoring starts for a dependency (after its source is discovered), we surface an available upgrade for any that's trailing the latest known release of its source: pinned version to latest, with risk aggregated across every release in that range, so a security fix or breaking change several versions back still counts even if the newest release is benign. We cross-reference our diff analysis to tell you things like 'react can move from 18.2.0 to 19.1.0 - HIGH RISK, it's a major version jump - and the range includes an undocumented useState behavior change.' Upgrades auto-resolve when a later sync shows you've bumped the dependency, and you can dismiss one to snooze it until a newer version appears.
Available upgrades clear themselves: when a later sync shows you've bumped the dependency to (or past) the offered version, the upgrade auto-resolves and drops off. There's no 'mark as read' anymore. If you're not ready to move, dismiss the upgrade to snooze it - it stays hidden until a newer version than the one you dismissed appears, then resurfaces with the new target. If you've connected our MCP server, an AI agent can do the same: it pulls your upgrades with get_available_upgrades, resolves the safe ones, and can call dismiss_upgrades to snooze any it's deferring (after actually bumping a dependency it usually doesn't need to, since the next sync auto-resolves the upgrade).
Yes. Every shared link expires automatically 7 days after you create it. You can also revoke a link sooner at any time. Each link only ever exposes the single release you shared, not the source's full history.
Free (Hobbyist) accounts can have up to 5 active share links at once. Revoke one or let it expire to free up a slot. Professional and Team plans have no limit on active share links.
For release tracking: any GitHub repository with tagged releases, VS Code extensions (via the Visual Studio Marketplace or the Open VSX Registry), the Google Ads API, and other release-notes or changelog pages via our generic source parser. For lockfile monitoring: npm (package-lock.json), Yarn (yarn.lock), pnpm (pnpm-lock.yaml), Go (go.sum), Rust (Cargo.lock), Python (poetry.lock, uv.lock, Pipfile.lock), and PHP (composer.lock).
Yes — and we verify your access using your own GitHub permissions, not just a shared backend token. The first time you point us at a private repo (as a tracked source or a live lockfile connection), you'll be asked to connect GitHub from Settings and install our GitHub App on the repository (or its owning org). The App requests read-only access to repository contents and metadata — never write — and you pick which repos it can see at install time. We then call GitHub as you, so a private repo only reveals data if GitHub itself confirms you have access. Access is read-only and revocable any time from github.com → Settings → Applications.
Two different jobs. The GitHub sign-in (per-user OAuth) gives us a short-lived token tied to your account that we use to ask GitHub "can this user see this repo?" — your repo access decisions are made by GitHub itself, not by us. The GitHub App install (per-repo or per-org) is what actually lets us fetch the lockfile contents on a recurring schedule. Sign-in alone is enough for public repos; private repos need both layers, because GitHub won't let us read private content on a schedule without an install. Both are read-only and independently revocable.
Your account stays signed in and your dashboard, digests, and uploaded lockfiles keep working. What stops working is the recurring fetch for any live lockfile connection on a repo the App used to reach: the next scheduled sync fails closed, the connection is paused, and you'll see an in-app dialog explaining that access was lost. To restore it, re-install the App on the repository (or have an org owner do so) and re-trigger the sync — no data is deleted in the meantime.
Yes. Connect your GitHub account from Settings → GitHub connection, then click "Sync stars" from the Sources tab or the same settings card. We pull your public stars and track each one as a source; private stars resolve only when our GitHub App is also installed on the owning user or org. If you have more stars than your plan's source limit, we'll open a picker so you can choose which ones to track. Un-starring a repo on GitHub deactivates the corresponding source on your next sync; re-starring reactivates it. If you manually deactivate a starred-sync source, future syncs leave it alone so the pause sticks.
Manually-added sources are kept first; bulk-synced starred-sync sources are deactivated before any manual ones, so the sources you curated by hand stay active. Within each group, most-recently-added rows are kept. Nothing is permanently deleted — deactivated rows can be re-enabled later by upgrading or re-syncing.
GitHub repositories work best when they publish tagged releases, since that gives us clean version boundaries for diff analysis. If a project publishes its releases elsewhere, you can still add it by pasting the URL of its release-notes or changelog page. If we have a deterministic parser for it, it's tracked reliably with no AI cost; otherwise it routes to our best-effort AI fallback, which you opt into explicitly (its first sync uses AI credits and results can miss or duplicate entries). Generic sources get AI release summaries, but git diff analysis and risk scoring run only on GitHub repository sources.
When you paste a URL that routes to the best-effort AI fallback, the Add source modal shows a 'Request a deterministic tracker' button. Add an optional product name and an example release link and submit — we log every request so we can prioritize by demand and build a stable, AI-free parser for it, usually within a few days. You can also email info@devupdate.io with the URL.
When you add a tracked source, we fetch the latest releases using GitHub's API. For each release, we compare it to the previous release using GitHub's comparison API to get the full diff. We then feed this diff (along with the release notes) to our AI, which identifies breaking changes, function signature modifications, export changes, and other critical updates. The AI explicitly flags discrepancies between what the changelog says and what the code shows.
We poll tracked sources on an adaptive cadence. Sources that are actively shipping are checked about once an hour; sources that have been quiet for a while are polled 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 source publishes again, it snaps back to the hourly cadence. You can also manually trigger a sync from the source detail page if you want an immediate update.
Yes, we use OpenAI's models to analyze diffs and generate summaries. The AI is specifically prompted to identify breaking changes, undocumented modifications, and security implications. While no AI is perfect, we've designed our prompts to be conservative - if there's ambiguity, we flag it for your review rather than ignoring it.
Every tracked source and lockfile dependency gets a 0–100 trust score that's a weighted blend of every reputable signal we can collect. OpenSSF Scorecard carries the heaviest weight (60%) for GitHub-backed projects — directly or via deps.dev for npm/PyPI/Go/Cargo packages. Alongside it we mix in raw GitHub signals (stars, forks, recency), deps.dev project signals (dependent count, license, last published), and an OSV.dev vulnerability check that subtracts up to 15 points when a package has known open advisories. When the GitHub composite is the only scored signal we have for a source, the blended score is capped at 69 (top of the MEDIUM band), so a niche but actively-pushed repo can't reach the HIGH band on stars and recency alone. VS Code Marketplace and Open VSX extensions blend marketplace signals (install count, ratings, verified-publisher flag, manifest) with an AI assessor. Web sources via the AI fallback parser stay AI-only. The badge labels the primary contributor — the signal with the largest weight — and the hover card lists every contributing signal so you can see what moved the score. See the docs page on trust scores for the full weight table.
We implement graceful degradation. If we hit GitHub's API rate limit while fetching diffs, we fall back to analyzing just the release notes for that release and mark the diff_fetch_status as 'rate_limited'. You'll still get a summary, just without the diff-based insights for that specific release. We automatically retry when rate limits reset.
DevUpdate.io is designed for senior developers, tech leads, and engineering managers responsible for maintaining complex codebases. If you've ever been burned by a 'minor patch update' that broke production, or spent hours investigating why a dependency update caused subtle bugs, this tool is for you.
We solve the 'silent break' problem - when library maintainers release updates with undocumented behavior changes. We also eliminate the noise of irrelevant changelog entries, helping you focus only on changes that could impact your codebase. Finally, we give you confidence to update dependencies by providing risk-based intelligence instead of forcing you to guess.
Instead of reading through dozens of changelog entries and release notes, you get a risk-scored, categorized summary highlighting what actually matters. You can quickly see if a new release has breaking changes, security updates, or undocumented modifications. When combined with lockfile monitoring, you get proactive, risk-scored available upgrades so you can pick up the safe ones and review the risky ones before they hit production.
Yes - we run a hosted MCP (Model Context Protocol) server that exposes your tracked sources, release analyses, and available dependency upgrades as tools any MCP-compatible client can call, so your agent can check real risk data and even work through your upgrades. It can call get_lockfile_upgrade_summary to triage which lockfiles need attention, get_available_upgrades to pull the per-package upgrades (pinned to latest, with priority and breaking/security flags), get_upgrade_details to read the release-by-release breaking changes and migration notes before taking a risky upgrade, and dismiss_upgrades to snooze any it's deferring. Point your client at https://api.devupdate.io/mcp and approve the connection on our consent screen - that's the whole setup for claude.ai, Claude Desktop, Claude Code (including web sessions, where you add it as a connector), and Cursor. Every client you authorize shows up under Settings → Connected AI Clients and can be revoked there at any time. For Claude Code we also publish a downloadable agent skill (docs → API & integrations → Agent skill) that teaches the agent the safe upgrade workflow end to end. Prefer to keep traffic off our hosted endpoint? The same server is available as a package you run locally with an API token. The step-by-step setup for every client is on the MCP server page in our docs, under API & integrations.
Currently, lockfile upload is manual via the web interface. In a future release, we're planning API endpoints for programmatic lockfile checking, which would enable CI/CD integration. You'd be able to upload your lockfile after dependency resolution and get immediate, risk-scored available upgrades for your dependencies.
We pull external context for the packages you track and surface it in two places. On a release summary, we attach security and ecosystem news published around the same time so you see the supply-chain context that release notes alone can't provide (for example, the recent LiteLLM credential leak). On the Pulse dashboard, the "News & discussions" section surfaces highly-engaged open GitHub issues on the repos you watch — so you can spot ongoing problems before they ship in a release or formal advisory.
Four sources today: (1) GitHub Security Advisories, structured CVE/advisory data with package-version ranges, (2) OSV.dev, the open-source vulnerability database covering npm, PyPI, Go, Maven, crates, and RubyGems, (3) a curated allow-list of security RSS feeds for narrative incidents that haven't landed as CVEs yet — passed through an LLM classifier that extracts affected packages and severity, and (4) GitHub Issues on each tracked repo, ranked by reactions and comments. HackerNews search, per-source blog/changelog feeds, and broader web mentions are on the roadmap.
The Pulse "News & discussions" section ranks each tracked repo's open issues by heat: reactions weighted 3×, plus comment count, decayed about 7% per day. An issue surfaces when its heat clears a minimum bar and it's been updated recently. The goal is to flag ongoing problems with momentum — heavily-reacted bug reports, hot proposals, paint-drying-slow regressions — before they bubble up into a release or advisory. Dismiss a row to remove it from your feed.
Yes. VS Code and Open VSX extensions are a first-class ecosystem. Advisories that affect a compromised editor extension are surfaced under a dedicated "vscode" ecosystem tag: GitHub Security Advisories file these under their npm ecosystem, so we re-tag known extensions back to vscode, and the LLM classifier labels narrative coverage of marketplace compromises the same way. You can also track a specific extension as a source — paste its Marketplace or Open VSX URL — to follow its version history and changelogs directly.
News items contribute up to 25 points to a release's 0–100 risk score, depending on how tightly they match. A direct critical match (a supply-chain compromise against the exact package) adds up to 25 points; a dependency-level critical match adds up to 10; ecosystem-wide critical news adds up to 5. The total score is still capped at 100, so a release with breaking changes and an unrelated upstream incident won't compound past that ceiling.
The scraper runs every 4 hours by default and indexes items from the last 14 days. When a release is processed, we only consider news published within ±14 days of the release date. Both the cadence and the lookback window are runtime-configurable without redeploying.
The most common reasons: (1) the news item names the package differently than we do (we canonicalize PyPI names but npm names must match exactly), (2) the item falls outside the 14-day window, (3) the RSS classifier couldn't extract a structured package name with high confidence, or (4) we don't have the package in our OSV probe list yet. Email info@devupdate.io if you spot a missed link and we'll add the mapping.
No, and that's intentional. We don't scan your code, we contextualize releases. A CVE scanner tells you "version 1.4.2 is vulnerable"; we tell you "this release of the library was published 8 hours after an upstream dependency was compromised." Socket is the closest tool to us here: it flags suspicious package behavior (new install scripts, network or filesystem access) when a dependency changes, while we focus on whether a release's code and API changes will break your build. Keep Dependabot, Snyk, or Socket running for software-composition and supply-chain scanning; use us to decide whether a specific update is safe to merge right now.
GitHub App lockfile syncing is available now: you can connect a lockfile to a GitHub repository (public or private) and we'll fetch it automatically on a schedule instead of relying on manual re-uploads. Still on the roadmap: (1) full codebase scanning where you can link your project and we'll auto-detect all your dependencies (today's lockfile auto-discovery is the first step), and (2) PR comments that surface our release analysis directly on your pull requests.
Yes! This is a major part of our roadmap. Instead of just monitoring libraries in general, we'll analyze your actual codebase to understand which specific functions and APIs you use. This way, we can tell you things like 'This update deprecates useState hook in React 18.3, which you use in 12 files.' This contextual intelligence is what transforms generic dependency monitoring into actionable project-specific insights.
Sourcegraph and similar tools index the codebase you already have for search, navigation, and AI-assisted editing. DevUpdate.io looks outward instead: for the GitHub libraries you depend on, we analyze the actual code diff of each release against the version before it. As our roadmap moves toward codebase-aware analysis, mapping a library's changes to the exact files that use them, the two directions will overlap more, but today they solve different halves of the problem.
Absolutely! Email us at info@devupdate.io with your ecosystem request. We prioritize based on user demand.
We store: your account information (email, username), URLs of the sources you track, the summaries we generate for each release, and parsed dependency data from lockfiles you upload. If you connect GitHub, we additionally store a short-lived GitHub App user access token (and its refresh token) against your account row so we can verify your access to repositories you ask us to read — both are deleted when you disconnect or delete your account, and the grant is revocable any time from github.com → Settings → Applications. We do NOT store your actual source code; private-repo access is mediated by your own GitHub permissions plus an App install you control per-repo. See the privacy policy for the full statement.
No. Your tracked sources and lockfile data are private to your account. The only exception is anonymized usage statistics for improving our service.
When you upload a lockfile, we parse it to extract package names and versions, then store this structured data in our database. We may optionally store the raw lockfile in S3 for audit purposes, but we never expose it to other users or third parties.
When you connect an AI client (Claude, Cursor, or any MCP app) to our hosted MCP server, it goes through an OAuth consent screen that lists exactly what it gets: reading your tracked sources, release analyses, and available dependency upgrades, plus dismissing upgrade notices. That's the entire surface - a connected client can't add or remove sources, upload lockfiles, change settings, or touch billing, and its tokens don't work on any other part of our API. We store only hashes of the issued tokens, every tool call is logged for audit, and each authorization or revocation lands in your account's security audit trail. To cut a client off, open Settings → Connected AI Clients and revoke it - its access stops immediately. API tokens (used for the self-run server, CI, or scripts) are revoked from Settings → API Token with the same immediate effect.
If your GitHub primary email is set to private, GitHub gives us a `users.noreply.github.com` address that bounces every transactional email we'd send you (sign-in verification, digest delivery, password reset, billing receipts). We ask for a reachable address once, send a one-click confirmation link to it, and use the verified address from then on. You can also make your GitHub email public from github.com → Settings → Emails if you'd rather not give us a separate one. Either way, you can change it later from Settings.
The Hobbyist tier is free forever: 100 tracked sources, 1 lockfile, daily digests, and 500 AI credits a month, with no credit card required. Professional is €12/month (€10/month billed annually) for unlimited sources and lockfiles, every notification frequency, and 5,000 AI credits a month (annual plans receive the full 60,000-credit yearly allowance up front). Team is €59/month (€49/month billed annually) and includes 5 seats. See the pricing page for the full comparison.
Under the EU 14-day right of withdrawal, you can cancel your initial subscription within 14 days of purchase. Because DevUpdate.io consumes AI credits the moment you use it, we ask you at checkout to confirm that you want service to start immediately. By doing so, your refund within the 14-day window becomes proportional to the credits you haven't used yet (refund = payment × (1 − credits_used ÷ credits_included)). If you've used 0 credits you get 100 % back; 30 % used means 70 % back; fully consumed means no refund is due. You can see the exact amount from Settings → Subscription → Request Refund, which shows a live preview before you confirm. The window applies only to your initial purchase; renewals and metered overage charges are non-refundable. The free Hobbyist tier lets you evaluate the service first.
For technical issues, email info@devupdate.io. For feature requests or general questions, you can also reach out on GitHub or Twitter/X.
Yes, you can request account deletion from your settings page. We'll send a confirmation email, and once confirmed, we'll delete all your data including tracked sources and uploaded lockfiles.
Free-tier accounts that have never added a tracked source and never connected a lockfile are automatically removed 30 days after signup. We send up to five reminder emails over the first 27 days (with the day-27 mail an explicit deletion warning), so you have plenty of time to add a source, connect a lockfile, or reply to tell us what's missing. Adding a single source or lockfile, upgrading to a paid plan, or joining a team removes your account from this cleanup. If your email is never verified, the account is removed at day 7 instead (with a reminder around day 4).
Can't find what you're looking for? Reach out to our support team.
info@devupdate.io