How locked in is your app?
Point infraveil-lockin at a repo and it prints a portability score, the provider you're most tied to, and a line-by-line inventory of what's trapping you — @vercel/kv, Next.js ISR, Cloudflare Durable Objects, DynamoDB, Firestore, Upstash — and exactly what it takes to leave each one. Zero dependencies, runs offline, talks to nobody.
What it does
One command, entirely on your machine, in a tool short enough to read end to end:
Finds what's trapping you
Every proprietary primitive your code actually touches, named and located — the exact dependency, config key, or API shape. Not a vague letter grade: a list of lines you can open and read.
Scores your portability 0–100
One number for how tied you are to a single provider, weighted by how hard each thing is to unwind. Track it over time; gate it in CI so it can only get better.
Tells you what it takes to leave
For every finding, the concrete move to get off it — what to stand up, what to rewrite, what data to migrate. The hardest ones are flagged so you plan the exit before you're forced into it.
Run it
No install, no account, no network. It reads your package.json, config files, and source signatures on your machine and prints the report:
Open your network tab while it runs — it talks to nobody. The score is a summary; the inventory it prints underneath is the part you act on.
Put it in CI
Drop one line in your pipeline to ratchet against new lock-in creeping in:
It fails the build if your app drifts past 60% locked to a single provider — so the next un-leavable primitive someone adds in a hurry can't slip in unnoticed.
What it detects
Weighted by how hard each is to unwind — a portable Postgres client behind a standard driver scores nothing; a Durable Object scores the most:
Vercel (managed KV/Postgres/Blob, ISR & revalidation, edge runtime, vercel.json), Cloudflare (Durable Objects, Workers KV, D1, R2, wrangler), AWS (DynamoDB, Serverless Framework, SAM/CDK, Lambda event shapes), Firebase/Firestore, Netlify, Heroku, Railway, Render, Fly.io, Supabase, PlanetScale, Upstash, Neon — and it credits the portable parts of your stack too.
Lock-in isn't created by hosting somewhere — it's created by adopting a provider's proprietary primitives. A Postgres database behind a standard driver is portable; the same data behind a managed proprietary store is a re-platforming project. The difference is invisible until you try to leave. This makes it visible — and every finding is a line you can verify yourself, trust by inspection, not a number on faith.
How the score works
It's a heuristic on top of an inventory you can audit — no black box:
…nudged up for portable dependencies. More proprietary primitives push it toward 0; a clean, portable stack sits at 100. Read lib/rules.js — the weights are plain data you can disagree with and change.
What it is — and isn't
It is an honest, offline read on your provider exposure and your exit surface: where you stand, what it would take to move, and a CI gate so it never silently gets worse.
It is not a migrator — it doesn't move your data. Knowing what's locked is step one; the move is yours. When you're ready to run on infrastructure you own without rebuilding the operations a platform did for you — supervision, backups, monitoring, audit — that's what Infraveil is for. This tells you where you stand; that helps you stand somewhere you own.
Prefer a zero-install web version? Use the Cloud lock-in checker. Then see what it costs to leave and generate a migration scaffold — Dockerfile plus runbook — for the move.