VPN Update Index

How this is calculated

Every number on this site comes from a public release record you can check yourself. This page gives you the whole formula, the sources, and the parts we know are imperfect.

What this measures, and what it does not

This index measures maintenance: whether a vendor is still shipping software to the people paying for it. Unmaintained VPN clients stop getting protocol fixes, operating-system compatibility patches, and responses to disclosed vulnerabilities, while the subscription keeps billing. That is a real and checkable risk, and almost nobody tracks it.

It is not a quality score. It says nothing about speed, server count, logging policy, jurisdiction, audit history, or whether a provider deserves your trust. A VPN can ship every week and still be a bad VPN. Use this to rule things out, then read a real review.

The formula

For each platform a vendor ships, we compute two things.

Recency — how long since the last release, decaying on a 45-day half-life.

recency = 0.5 ^ (days_since_release / 45)

A release today scores 1.0. 45 days ago, 0.5. 90 days ago, 0.25. A year ago, effectively zero.

Cadence — how many releases in the past year, capped at 12.

cadence = min(1, releases_in_365_days / 12)

Shipping 12 times a year earns full marks. Shipping 60 times earns exactly the same — volume past monthly is not evidence of better maintenance.

Platform score weights recency more heavily than cadence, because a vendor that shipped steadily and then stopped is the exact failure this site exists to catch.

platform = 0.6 × recency + 0.4 × cadence

The index is the weighted average across the platforms a vendor actually ships, multiplied by a coverage factor.

index = 100 × weighted_average × coverage coverage = 0.75 + 0.25 × (platforms_shipped / all_platforms)

Coverage never drops below 0.75, so a small provider that maintains three platforms well is not crushed by a large one that maintains eight indifferently. It still rewards breadth, because an abandoned Linux client is a real problem for the people using it.

Platform weights

PlatformWeight
Windows1.0
Android1.0
iOS1.0
macOS0.9
Linux0.7
Chrome0.5
Firefox0.5
CLI0.3

Rules that stop the score being gamed

Where the data comes from

SourceCoversMethodHistory
Apple App StoreiOS, macOSiTunes Lookup APICurrent version only
Google PlayAndroidStore listingCurrent version only; Play publishes no version string, so we key on the date
Chrome Web StoreChromeStore listingCurrent version only
Mozilla Add-onsFirefoxAMO public APIFull dated history
winget-pkgsWindowsMicrosoft manifest repoFull dated history
ChocolateyWindowsCommunity OData feedFull dated history; volunteer-maintained, can lag
Homebrew CaskmacOShomebrew-cask commit logFull dated history; volunteer-maintained, can lag
GitHub ReleasesLinux, CLI, apps built in the openGitHub APIFull dated history

How we check our own numbers

Being wrong about a real company is the failure mode that matters here, so the data is checked four ways, and the checks are part of the build rather than something we did once.

Why "last release" can flatter a vendor

The date in the leaderboard is the vendor's freshest platform. A provider can ship a routine phone update while their desktop client and browser extension sit untouched for years, and that single date would make them look active.

So where a vendor's stalest platform trails its freshest by more than six months, the leaderboard says so directly — "oldest 3 years ago" beside the headline date. The index already accounts for this, because it averages across every platform a vendor ships rather than taking the best one; the warning exists so the table does not tell a rosier story than the score.

Known gaps

These are limitations we would rather state than have you discover.

Independent audits

Audit records are curated by hand from vendors' own publications. There is no API for this, and an audit is a claim about a real company, so nothing here is inferred: every record links to a primary source, and scripts/verify-audits.ts re-checks each link on every build.

Audits are shown beside the index and never inside it. Folding them in would mean weighting a Cure53 app pentest against a Deloitte no-logs engagement, which are not the same thing and cannot be fairly traded off against each other in one number.

The attention chart

The attention page plots relative Google search interest. It is genuinely interesting and it is not part of the index, because search volume mostly tracks advertising spend. A ranking weighted by it would be a ranking of marketing budgets, which is the thing this site exists to be an alternative to.

Google Trends compares at most five terms at a time and rescales each query to 0-100 against that query's own peak. To place every brand on one axis we run batches of four brands plus a shared anchor brand and rescale each batch so the anchor matches. Two consequences worth stating:

Money

Some outbound links are affiliate links and we may earn a commission. The ranking code never reads the affiliate list — it is a separate file, loaded by the page renderer and not by the scorer. Every input to the index is public, so if a ranking ever looked bought, it could be checked and disproved. That is the point of publishing the formula.

Corrections

If a vendor is mapped to the wrong app, or ships a platform we are missing, that is a bug worth fixing. The whole release history is public data — send the identifier and we will add it.

Rebuilt daily at 5:00 PM Pacific.