Live lockfile connection

A live lockfile connection links a monitored lockfile to a GitHub repository so DevUpdate.io fetches that lockfile's contents on a schedule and recomputes its available upgrades for you. Instead of re-uploading a file every time your dependency tree changes, the connection keeps your monitoring current automatically.

Prerequisite: connect GitHub #

Live lockfile connections, public and private, require a GitHub OAuth connection on your account. We use your own OAuth token to verify that the repository you're connecting to is one you actually have access to on github.com, so DevUpdate.io can never read a repo you don't already have access to. Connect it from Settings → GitHub connection if you haven't yet.

If you skip this step, attempting to connect a repository will redirect you back to Settings with a prompt to connect GitHub first.

Repositories with access #

The Lockfiles tab shows a Repositories with access panel listing every repository you've granted the DevUpdate.io GitHub App: exactly the repos you picked at install time, nothing more. Each row has a Scan for lockfiles button that opens the connect dialog already pointed at that repo and immediately scans it, so you never have to paste a URL for a repo you've already connected.

The same list also powers a Your repositories picker at the top of the connect dialog: start typing to filter, pick a repo, and we fill in the URL (and scan, on the Scan tab) for you. You can still paste any repository URL by hand for a public repo you haven't installed the App on.

To change which repositories the App can see, use Manage repository access (in the panel header and next to the picker). It opens GitHub's App installation settings, where granting or removing repo access is GitHub's decision, not ours; the panel reflects whatever you set there on its next refresh.

Three ways to find your lockfile #

When you click Connect GitHub Repo, the dialog offers three picker modes: pick whichever fits the situation. Repository URL and branch are shared across all three.

• Scan (recommended): type the repository URL, click Scan, and we walk the whole repo and list every supported lockfile we find. Tick the ones you want; you can pick more than one and we'll create a separate monitored lockfile for each in a single submit. Best for monorepos with multiple lockfiles or when you don't remember the exact path.
• Browse: desktop-style folder navigator. Expand directories to drill into the repo and tick the lockfile(s) you want. Useful as a fallback when Scan can't reach into a very large repo (we'll tell you when that's the case), or when you'd rather pick visually.
• Manual: type the lockfile path yourself (for example package-lock.json or backend/go.sum). Best when you already know the exact path or you're rebinding an existing connection.

Multi-select #

In Scan and Browse you can tick several lockfiles at once. We create one monitored lockfile per selected path; each is named after its in-repo path (for example frontend / yarn.lock) and can be renamed, auto-sync-toggled, hidden from AI agents, or disconnected independently.

Hiding a lockfile from AI agents #

Each lockfile has an Available to AI agents toggle (on its card's overflow menu and the lockfile detail page; default on). Turn it off to keep the lockfile fully monitored here (it still syncs and still shows its upgrades and security issues on your dashboard) while excluding it from the MCP server, so connected agents don't see it in get_upgrades or get_security_issues. It's independent of Active/Inactive (which pauses monitoring for everyone) and of auto-sync. You don't need it just to keep an agent working in one repo out of your others: the skills already scope each call to the repo the agent is in. The toggle is for a lockfile no agent should read at all.

No duplicates #

Each repository file is tracked once. If a scan turns up a lockfile you already connected, it appears as Already tracked and can't be re-selected, and connecting the same repo file again is skipped rather than creating a second copy. This holds across Scan, Browse, and Manual, so connecting a repo and later scanning it can't leave you with duplicate cards for the same file.

Manual uploads are adopted, not duplicated #

If you uploaded a lockfile by hand first and later connect the repository it came from, we recognize the match (the same content, or a manual lockfile of the same type whose packages mostly overlap the repo file's) and upgrade your existing manual lockfile to a live connection in place instead of creating a second record. Everything attached to it carries over: your name for it, the packages you selected for monitoring, their watched sources, and any dismissed upgrades. There's nothing to clean up afterwards; the connect dialog tells you when a selection was matched to an existing manual lockfile this way. Packages the repo file has that your upload didn't are new to the lockfile, so they're tracked automatically.

Connecting a public repository #

1. From the dashboard, open the Lockfiles tab.
2. Choose to connect a repository instead of uploading a file.
3. Enter the repository (<owner>/<repo>) and pick lockfiles using Scan, Browse, or Manual as described above.

DevUpdate.io verifies your access with your GitHub OAuth token, then fetches each selected lockfile and starts monitoring it.

Connecting a private repository #

Two layers protect private content:

• Your OAuth token gates access. When you click connect, we call GitHub as you. If GitHub itself doesn't grant you access to the repo, the connection is rejected; no shared backend token can override this.
• Our GitHub App handles the recurring fetch. Install the DevUpdate.io GitHub App on the repository (or grant the existing installation access to it) so we can keep fetching the lockfile on the scheduled cadence below. The App has read-only access scoped to the repositories you select; the access decision is still gated by your user-level permission, never just the App's.

Access requirements #

For a successful private-repo connection, or a successful re-sync of an already-connected one, both of the following must hold at the time of the request:

1. You have repo access on github.com. That means one of:
   • You're a collaborator on the repository, or
   • You're a member of an organisation team that has read (or higher) access to the repository. If neither is true, GitHub itself denies our read call on your behalf and DevUpdate.io shows a "no access to owner/repo" dialog; there's no setting on our side that can unblock it.
2. The DevUpdate.io GitHub App is installed on the repository. For personal repos, you install it yourself. For org-owned repos, an org owner installs it (or extends an existing install to include the repo). The App can be uninstalled at any time from github.com → Settings → Applications on a personal account, or the equivalent Organization settings → GitHub Apps page for orgs.

If access is later revoked (you leave the org, or the App is uninstalled) the next scheduled sync fails closed with the same dialog, and the lockfile's connection is paused until access is restored.

Jumping to the source on GitHub #

Open a connected lockfile's detail view and you'll find a View on GitHub button next to Update. It deep-links straight to the tracked file on its branch (or the repository root if no specific file path was recorded), so checking the real lockfile on github.com is always one click away. Manual uploads have no repository to point at, so the button only appears on live connections.

Polling cadence #

Connected lockfiles are fetched hourly. (Release polling for tracked sources uses an adaptive cadence, hourly while a source is active, easing off to at most daily when it's quiet, but lockfile fetches stay on a fixed hourly schedule.) Each fetch recomputes the lockfile's available upgrades the same way a manual re-upload does: upgrades the sync shows you've taken auto-resolve and drop off, and any newly-available ones appear. Newly-available upgrades don't email you, whatever risk level they carry: a high-risk upgrade means risky to adopt (a major jump, or documented breaking changes), which is something to plan around rather than be interrupted for. You read those on the lockfile page. The one thing an unattended sync does email about is a newly-disclosed critical or high severity advisory against a version you pin (see security issues).

On the Lockfiles tab each connected lockfile shows when it last synced as relative time ("Last synced 12 minutes ago", with the exact timestamp on hover) next to an Auto-syncs hourly indicator, so it's clear the monitoring stays current on its own. The Re-sync button is only for when you want to fetch immediately instead of waiting for the next hourly run; you never have to press it to stay up to date.

New dependencies are tracked automatically #

When a sync finds a dependency that wasn't in the lockfile before, we start monitoring it right away: it's matched to its GitHub repository and tracked exactly as if you had ticked it under Package Sources and pressed Save Changes. Add a package in your repo, and by the next sync it's on your dashboard, with its upgrades and release notes, without you opening the lockfile at all. A new package shows as selected while it's being matched, and if that work is interrupted (a deploy, say), it's picked up again automatically, usually within a few hours.

Only added packages are affected. A package that was already in the lockfile keeps whatever you chose for it: unchecked stays unchecked (even if it leaves the lockfile and comes back later), and one you never selected stays unselected. A package you already track through another lockfile (from the same registry) is linked to that same source rather than tracked twice. One whose source you paused on the Sources tab stays paused and is added unchecked, so a later Save doesn't switch it back on. And a Save from a page you opened before a sync added something leaves those new packages as they are. New packages count toward your source limit like any other: your plan's, and the account ceiling every plan has. One that belongs to a repository you already watch takes no slot, so it is still linked when you're at the limit. One we can't track, because it has no GitHub repository we can match or you're at your limit, shows in the lockfile's Discovery failed list with the reason.

Two cases are left for you rather than tracked automatically. A deactivated lockfile gains no new sources, since you've switched its monitoring off. And a change that replaces most of the lockfile at once, which usually means a different file (the wrong project re-uploaded, or a lockfile connected to another repository's file), adds its packages unchecked so you can review them first.

Removing a dependency works differently: it doesn't stop monitoring. A package that leaves the lockfile drops out of its Package Sources list, but its source stays on your Sources tab (another lockfile, or another project, may still use it). To stop following it, untick it before you remove it, or pause the source on the Sources tab.

This is on for every lockfile by default. To review new dependencies yourself instead, untick Track new dependencies automatically in the lockfile's Package Sources section: new packages then appear unchecked until you select them, and any still being matched when you turn it off are left for you too. The setting is per lockfile, and it applies to manual re-uploads as well as syncs.

What we store #

We store only the parsed dependency data: a map of package names to versions. We do not persist the raw lockfile bytes or any other contents of your repository; the file is parsed and discarded after each fetch. See Account → Privacy for the full data-handling breakdown.

Plans and limits #

Automatic syncing is available on all plans: Hobbyist, Professional, and Team. A connected lockfile counts against your normal lockfile limit (2 on Hobbyist, unlimited on Professional and Team), the same as an uploaded file. See Billing → Plans.

Disconnecting and revoking access #

You can disconnect a live lockfile connection from the Lockfiles tab at any time, which stops the scheduled fetches. To fully revoke our access:

• Uninstall the DevUpdate.io GitHub App, or remove the repository from the App's access list, in your GitHub repository / organisation settings.
• Revoke the DevUpdate.io OAuth grant from github.com → Settings → Applications. This takes effect on our next call without any action on our side: the next sync attempt will fail closed and the connection will be paused.

What's next #

• Uploading a lockfile: the manual upload flow.
• Available upgrades: how upgrades are surfaced, how risk is aggregated, and the auto-resolve / dismiss lifecycle.