Reading Bubble from the outside

Why you are getting this

You confirmed a signup for bubbleio.wtf launch updates, and the promise was “one email when migrations open, plus occasional build notes”. This is the first build note: what the scanner can now see, and what it means for anyone deciding when to move off Bubble. When migrations open, that will be its own email.

Every issue also lives at bubbleio.wtf/newsletter, so you can link it later. Reply to this email and it comes to me, not a queue.

The aha

The scanner reads Bubble apps from the outside: no login, no editor access, just the public bundle. Run that for a year and you end up with something I did not set out to build — a view of Bubble’s own customer base.

As of today, across the 20,472 Bubble apps it tracks:

“Readable live version” is the honest headline, not “paying customer”. Bubble serves no live version on a plan that cannot publish, so a readable live version is the closest observable stand-in for “this app is on a plan that can ship”.

The part I did not expect is a cohort. Of the 14,537 apps I could read in October 2025, 9,604 still answer today — 66%. Of the rest, 1,539 have lost their live version, 568 are no longer Bubble apps at all, and 739 now only answer on /version-test.

That last group is the interesting one for anyone weighing a migration: an app going dark is rarely a cancellation. It is a rebuild, an abandoned side project, or a downgrade — and only one of those three is a happy ending.

This is alpha, and I will say so plainly. It is an admin view, not a product. Scan history is stored as each version’s last result, so I can say what an app looks like now, not what changed in which week. Recording state changes is the next piece of work before any of this deserves to be called churn. I am not publishing Bubble revenue estimates; if this becomes a real chart, it will carry its method and its gaps, not just a number in a headline.

What the scanner found this week

371,903 scans have produced 26,708 keys that a provider’s own API confirmed. The shapes repeat: the same provider, the same field, the same mistake.

The families, by confirmed key count: Slack webhooks (11,662), Google Gemini keys (1,648), Slack tokens (1,508), Apify (1,298), HubSpot (741), Shopify (571), OpenAI (565), SendGrid (550).

One caveat in the same breath: webhook-shaped detectors are lenient. A well-formed hooks.slack.com URL counts as live, so read that first number as “posted keys”, not “working keys”. The provider API checks behind the rest are stricter.

Full ranking: bubbleio.wtf/tools/leaked-keys/top.

Tools that changed

• Claim your app (beta) — prove an app is yours by putting one short marker on a version-test page, then work from your own dashboard: rescan on demand, see the keys, and check a fix after you rotate it, instead of reading an email and guessing. It works end to end today, but treat it as beta — rough edges are likely, and telling me where they are is the whole point of opening it early.
• Project browser — paste a Bubble app URL and get its data model back as a blueprint.
• DBML export — the same model as a DBML file your team can version.
• Leaked-key check — read-only, names the provider and where in the app the key sits.
• Migration assessment — what a migration would actually involve for an app like yours.

From the blog

Eight guides so far. The two that get read most are the unglamorous ones: what to rebuild first, and how to scope the work before you commit to it. Read them all.

Next

Migrations open soon, and the scanner is the front door: if your app leaks keys, fixing that and planning the move are the same conversation.

— Rico