DEV Community: Perufitlife

Free open-source security auditors for Supabase, Strapi, Hasura, Convex, Ollama & more

Perufitlife — Tue, 23 Jun 2026 01:14:20 +0000

Most backend data leaks aren't clever hacks. They're a database, CMS or API left readable by the anonymous / public role — a default someone forgot to lock down before going to production.

So I built a family of open-source auditors (MIT, zero dependencies) that check for exactly that, and confirm each leak with a read-only anonymous probe — the same request any visitor's browser makes. Nothing is downloaded, nothing is changed. You get the bytes that are actually exposed, not a guess from a config file.

One command each:

npx strapi-security   --url https://your-strapi.example.com
npx directus-security --url https://your-directus.example.com
npx hasura-security   --url https://your-hasura.example.com
npx convex-security   --url https://your-app.convex.cloud
npx ollama-security   --url http://your-host:11434
npx payload-security  --url https://your-payload.example.com
npx n8n-security      --url https://your-n8n.example.com

Plus auditors for Supabase, Firebase, PocketBase, Appwrite and Nhost, and tools for served secret files (.env, .git, source maps) and Claude Code .claude/ config footguns.

Full collection, all MIT:
https://github.com/Perufitlife/awesome-backend-security

Want me to run one for you — free?

If you'd rather not install anything, drop your backend URL and I'll run the matching auditor and post the findings + the exact fixes back to you, free. Read-only, nothing downloaded.

Request a free audit: https://github.com/Perufitlife/awesome-backend-security/issues/new?template=free-audit.yml

If it turns up something and you'd like the fixes done for you, there's a fixed-scope $99 option — but the tools and the audit are free, and that's the point: most of these holes take five minutes to close once you know they're there.

I gave my AI agent live aviation weather — building a free Aviation MCP server

Perufitlife — Sun, 14 Jun 2026 02:26:02 +0000

I'm a commercial pilot who builds software. Last week I noticed something: ask any AI assistant "what's the weather at JFK right now and is it VFR?" and it either guesses, hallucinates a METAR, or tells you to go check a website. LLMs have no live aviation data.

So I built an MCP server that fixes that. It gives Claude, ChatGPT, Cursor — any MCP client — six aviation tools that return real data:

get_metar — current decoded METAR for any ICAO airport (flight category, wind, visibility, temp, dewpoint), optional TAF
get_airport — airport info by ICAO (name, IATA, city, coordinates, elevation, runways)
get_aircraft — aircraft specs by slug (engines, range, cruise, ceiling, MTOW, type rating)
get_glossary_term — definitions from an aviation glossary
practice_questions — FAA-style exam questions with answers
quiz_of_the_day — a daily aviation question

No API key. No signup. It's a thin MCP wrapper over a free aviation API I maintain (Rotate Pilot), so the tools are just typed HTTP calls — the hard part is the data, not the protocol.

Why MCP, and why this was easy

The Model Context Protocol is becoming the default way to hand tools to LLMs in 2026 — Claude, Cursor, Cline, Continue and Windsurf all speak it. If you have any API, wrapping it as an MCP server drops it into every AI client at once. That's a free distribution channel most API owners are sleeping on.

The server runs as an Apify Standby Actor (Streamable HTTP /mcp + legacy SSE), using the official @modelcontextprotocol/sdk. Each tool definition is ~10 lines: a name, a JSON schema, and a buildPath(args) that returns the API path. The server fetches it and returns the JSON. That's the whole thing.

Connect it

{
  "mcpServers": {
    "aviation": {
      "url": "https://renzomacar--aviation-mcp.apify.actor/mcp?token=YOUR_APIFY_TOKEN"
    }
  }
}

Then ask your agent: "Pull the METAR for KSFK and EGLL, tell me which is VFR, and compare a Cessna 172 to a Piper Warrior on cruise speed." It will call the tools and answer from real data.

Try it / source

GitHub (MIT): https://github.com/Perufitlife/aviation-mcp
Apify Store: https://apify.com/renzomacar/aviation-mcp
The underlying free API + OpenAPI spec: https://rotatepilot.com/developers

Curious what other niche data verticals are still missing from the MCP ecosystem — aviation felt like an obvious gap for a pilot. What's yours?

Build a Lead-Gen Automation in n8n: Scrape, Enrich, Export

Perufitlife — Fri, 12 Jun 2026 12:45:42 +0000

Most "lead generation" tutorials stop at scraping a list of business names. But a name and a phone number isn't a lead - a name, a decision-maker email, and a verified contact channel is. In this tutorial we'll build a complete lead-gen pipeline in n8n that does all three stages: scrape businesses from Google Maps, enrich them with emails crawled straight off their websites, and export a clean list to Google Sheets.

No code, no scraper maintenance. We lean on n8n's generic Apify node to run two ready-made actors and chain them together.

The pipeline at a glance

Trigger -> Scrape (Google Maps) -> Enrich (Website Contact Finder) -> Export (Sheets)

Scrape - pull businesses for a niche + city from Google Maps (name, phone, website, rating).
Enrich - take each business website and crawl it for emails, phones, and social links.
Export - write the merged record to Google Sheets as one row per lead.

Stage 1 gives you reach. Stage 2 gives you the email that actually makes the lead actionable.

Prerequisites

A running n8n instance (cloud or self-hosted).
A free Apify account. Grab your Personal API token from Settings -> Integrations.

That's it. Both actors we use are on the Apify Store and run through the same generic Apify node, so you only configure one credential.

Step 1 - Add the Apify credential

Add a node in n8n, search Apify, choose the generic Apify node. When it asks for credentials, select Apify API and paste your token. Save. You'll reuse this credential for both the scrape and enrich steps.

Step 2 - Scrape businesses from Google Maps

Add your first Apify node. Configure it to run the Google Maps Email Extractor actor (renzomacar/google-maps-businesses):

Operation: Run actor and get dataset
Actor: renzomacar/google-maps-businesses
Input (JSON):

{
  "searchQueries": [
    "marketing agencies in Denver CO"
  ],
  "maxResultsPerQuery": 50,
  "language": "en",
  "includeWebsite": false
}

Notice includeWebsite is false here. We deliberately keep this stage fast and cheap - we just want the business list and their website URLs. The deep email crawl happens in the next step with a dedicated tool that does it better.

Each output item looks like:

{
  "name": "Summit Digital",
  "phone": "+1 720-555-0142",
  "website": "https://summitdigital.co",
  "rating": 4.8,
  "reviewsCount": 96
}

Step 3 - Enrich each business with emails

Now the enrichment step. Add a second Apify node, this time running the Email & Contact Finder actor (renzomacar/website-contact-finder). This actor crawls a website's contact, about, and team pages and extracts emails, phone numbers, social profiles, and even the tech stack.

The trick is feeding it the website URLs from Step 2. The actor takes a domains array, so collect the websites from the previous node and pass them in. A simple way: drop a Code node between the two Apify nodes to gather the URLs.

// Code node: collect website URLs from the Google Maps results
const domains = items
  .map(i => i.json.website)
  .filter(Boolean);

return [{ json: { domains } }];

Then configure the second Apify node:

Operation: Run actor and get dataset
Actor: renzomacar/website-contact-finder
Input (JSON):

{
  "domains": {{ $json.domains }},
  "maxPagesPerDomain": 4,
  "includeGenericEmails": true,
  "detectTechStack": true
}

The domains value is mapped from the Code node, so it scales automatically with however many businesses you scraped. Each enriched result comes back like:

{
  "domain": "summitdigital.co",
  "emails": ["hello@summitdigital.co", "jobs@summitdigital.co"],
  "phones": ["+1 720-555-0142"],
  "socialLinks": {
    "linkedin": "https://linkedin.com/company/summit-digital",
    "instagram": "https://instagram.com/summitdigital"
  },
  "techStack": ["WordPress", "HubSpot"]
}

Now you have an email and a social channel for outreach - the difference between a raw list and a usable pipeline. Bonus: the detected tech stack lets you segment ("everyone on HubSpot," "everyone still on WordPress") for sharper messaging.

Step 4 - Merge and export to Google Sheets

You've got two datasets: businesses (Step 2) and contacts (Step 3). Use n8n's Merge node set to Combine -> Merge By Key, keying on the website/domain so each business lines up with its scraped emails. Then add a Google Sheets node with operation Append Row and map the columns:

Sheet column	Expression
Business	`{{ $json.name }}`
Email	`{{ $json.emails[0] }}`
Phone	`{{ $json.phone }}`
Website	`{{ $json.website }}`
LinkedIn	`{{ $json.socialLinks.linkedin }}`
Tech	`{{ $json.techStack.join(", ") }}`

Run it. Each row is now a real, enriched, ready-to-contact lead.

Step 5 - Put it on a schedule

Swap the manual trigger for a Schedule Trigger and rotate your searchQueries across cities and niches. Every run adds fresh, enriched leads to the sheet with no manual effort. Add a dedupe step (key on email or domain) if you run overlapping searches.

Why split scrape and enrich into two actors?

You could ask the Google Maps actor to visit websites itself (includeWebsite: true) and call it a day. That's fine for small jobs. But splitting the stages gives you two wins: the scrape stays fast and cheap, and the enrichment is far more thorough - the contact-finder actor crawls multiple pages per domain (contact, about, team) rather than just the homepage, so it surfaces emails the quick pass misses. For serious outreach lists, the two-stage pipeline pulls noticeably more verified emails.

Wrap-up

That's a full lead-gen machine in n8n with zero scraping code:

Scrape with Google Maps Email Extractor
Enrich with Email & Contact Finder
Export to Sheets, on a schedule

Both actors run through the same generic Apify node, so once your token is in, you can recombine them into any pipeline you like - reviews monitoring, competitor research, recruiting, you name it.

Now go fill that sheet.

How to Scrape Google Maps Leads in n8n Without Code (Emails + Phones)

Perufitlife — Fri, 12 Jun 2026 12:44:28 +0000

Lead generation usually means one of two painful things: paying for an expensive SaaS seat, or hand-copying business names and phone numbers off Google Maps one card at a time. If you already run n8n for your automations, there is a third option that takes about ten minutes to set up and needs zero code.

n8n ships with a generic Apify node. That node can run any actor on the Apify Store and hand you back structured JSON you can pipe into Sheets, a CRM, or an email step. So instead of building a scraper, you point the node at a ready-made one. In this tutorial we will use a Google Maps scraper that pulls business names, phone numbers, websites, ratings, and emails, then drop the results into Google Sheets.

No browser automation to maintain, no proxies to rotate, no captcha headaches. Let's build it.

What you'll build

A 3-node n8n workflow:

Manual / Schedule trigger - kick the run off on demand or nightly
Apify node - run a Google Maps scraper actor with your search terms
Google Sheets node - append every business as a new row

The output is a clean lead list: business name, address, phone, website, rating, review count, and (optionally) the email scraped from the business website.

Step 1 - Get an Apify token

You need a free Apify account. After signing up, go to Settings -> Integrations and copy your Personal API token. The free tier comes with monthly platform credit, which is plenty for testing and small lead lists.

Step 2 - Add the Apify credential in n8n

In n8n, open any workflow and add a new node. Search for Apify and pick the generic Apify node (it talks to the Apify API directly - no custom community node required).

When prompted for credentials, choose Apify API and paste the token from Step 1. Save it. That credential is now reusable across every Apify-powered workflow you build.

Step 3 - Point the node at the Google Maps actor

The Apify node asks for an Actor to run. We'll use the Google Maps Email Extractor actor (renzomacar/google-maps-businesses). It scrapes Google Maps search results and returns structured business data, and it can optionally visit each business website to grab an email - which is exactly what makes it useful for outreach.

In the node:

Operation: Run actor and get dataset
Actor: renzomacar/google-maps-businesses
Input (JSON): paste the config below

{
  "searchQueries": [
    "dentists in Miami FL",
    "coffee shops in Austin TX"
  ],
  "maxResultsPerQuery": 50,
  "language": "en",
  "includeWebsite": true
}

A few notes on these fields:

searchQueries is an array, so you can batch several searches in one run. Use the same phrasing you would type into Google Maps: "<business type> in <city>".
maxResultsPerQuery caps how many businesses per query. Google Maps tops out around 120 per search, so anything up to that is realistic.
includeWebsite: true tells the actor to open each business website and extract emails and social links. This is the magic toggle for outreach - leave it off if you only need phone numbers and want a faster, cheaper run.

Run the node once. You should get an array of business objects back, each looking roughly like this:

{
  "name": "Bright Smile Dental",
  "address": "123 Biscayne Blvd, Miami, FL 33132",
  "phone": "+1 305-555-0199",
  "website": "https://brightsmilemiami.com",
  "email": "hello@brightsmilemiami.com",
  "rating": 4.7,
  "reviewsCount": 214,
  "category": "Dental clinic"
}

Step 4 - Send the leads to Google Sheets

Add a Google Sheets node after the Apify node. Authenticate with your Google account, pick (or create) a spreadsheet, and set the operation to Append Row.

Map the columns to the fields coming out of the Apify node:

Sheet column	n8n expression
Business	`{{ $json.name }}`
Phone	`{{ $json.phone }}`
Email	`{{ $json.email }}`
Website	`{{ $json.website }}`
Rating	`{{ $json.rating }}`
Address	`{{ $json.address }}`

Because the Apify node outputs one item per business, n8n loops automatically - every business becomes its own row. Run the workflow and watch the sheet fill up.

Step 5 (optional) - Email the list to yourself

Want the lead list in your inbox instead? Swap (or add) an email / Gmail node at the end. Pipe the dataset through a small Code or Set node to format it as an HTML table, then send. Now you have a nightly "fresh leads" email with zero manual work.

You can also flip the Apify actor's outputFormat to html-report and it returns a polished, scored lead-list report you can attach directly - handy if you're delivering these to a client.

Make it run on autopilot

Replace the manual trigger with a Schedule Trigger (say, every Monday at 8am) and rotate your searchQueries - different cities, different niches - so each run brings in net-new leads. That's a self-refilling pipeline without writing a single line of scraping code.

Why the node-based approach beats DIY scraping

If you tried to scrape Google Maps yourself inside n8n with an HTTP Request node, you'd immediately hit dynamic JS rendering, rate limits, and layout changes that break your selectors every few weeks. Offloading that to a maintained actor means the brittle part is someone else's problem - you just consume clean JSON. That's the whole point of the Apify node: scraping becomes a single configured step in your automation, not a project.

Wrap-up

In a handful of nodes you've got a no-code lead-gen pipeline: search Google Maps -> extract names, phones, websites and emails -> append to Sheets or email yourself -> schedule it. The same pattern works for any niche and any city.

If you want to go deeper on the contact-enrichment side, the Google Maps Email Extractor actor and its companion contact-finder are both on the Apify Store and run inside n8n exactly the way shown here.

Happy automating.

Healthcare Lead Generation With the Free NPI Registry (and How to Add the Missing Emails)

Perufitlife — Fri, 12 Jun 2026 12:23:03 +0000

If you sell to clinics, doctors or dentists in the US, you're sitting on top of one of the cleanest free B2B datasets that exists and most people ignore it. The NPPES NPI registry is a government database of every healthcare provider in the country, it has a public JSON API, and there's no key, no scraping and no terms-of-service grey area. The catch: it gives you who and where, but not the email. This post is about closing that gap.

What the NPI registry actually is

Every US provider that bills insurance has an NPI (National Provider Identifier). The Centers for Medicare & Medicaid Services publish the whole thing through NPPES, and there's a documented public API: npiregistry.cms.hhs.gov/api-page.

You can query by name, specialty (taxonomy), city, state or postal code. Each record gives you:

Provider or organization name
NPI number (so every lead is verifiably real)
Primary taxonomy / specialty
Practice address and phone
Whether it's an individual (NPI-1) or organization (NPI-2)

That's already more structured and more trustworthy than most paid lead lists, because every row maps to a government-verified identifier.

Pulling a target segment

Say you want dentists in Austin, TX. The API takes simple query params:

const params = new URLSearchParams({
  version: '2.1',
  taxonomy_description: 'Dentist',
  city: 'Austin',
  state: 'TX',
  limit: '200'
});

const res = await fetch(`https://npiregistry.cms.hhs.gov/api/?${params}`);
const { results } = await res.json();

const leads = results.map(r => ({
  npi: r.number,
  name: r.basic.organization_name
        || `${r.basic.first_name} ${r.basic.last_name}`,
  taxonomy: r.taxonomies.find(t => t.primary)?.desc,
  address: r.addresses.find(a => a.address_purpose === 'LOCATION'),
}));

The limit caps at 200 per call and results are paginated with skip, so you loop in pages until you've covered the segment. Be gentle with request rate — it's a public good, not a private API you're paying to abuse.

The missing piece: emails

NPPES deliberately does not publish email addresses. So a raw NPI pull is a list of verified practices with phone + address but no inbox. To turn it into something you can actually run a cold email campaign against, you enrich each record with the practice's own website and the email published on it.

The enrichment chain per lead:

Find the website. The NPI address + name is usually enough to resolve the practice site (a places lookup, or a constrained web search by name + city).
Crawl the contact pages. Same trick as any contact scraper — fetch /contact, /about, /appointments etc. first, decode obfuscated info [at] clinic [dot] com addresses, and filter image/asset false positives.
Keep the NPI as the join key. Because every record has a unique NPI, you can dedupe and re-enrich cleanly later without guessing whether two rows are the same practice.

This is the part that's tedious to maintain by hand: resolving the site, handling the 10-20% of practices with no site or a Facebook-only presence, retrying flaky requests, and not getting rate-limited across thousands of small clinic sites.

I packaged the whole chain — NPI pull plus website resolution plus contact-page crawl — as a hosted, pay-per-lead scraper: Healthcare Provider Leads. You give it a specialty + location, it returns NPI-verified providers with name, specialty, address and phone, plus the emails and socials enriched from their sites. No API key, and you pay per lead delivered rather than per month.

If you want to enrich a list of arbitrary practice websites you already have (not NPI-sourced), the generic Email Scraper & Contact Finder does just the crawl-and-extract step on any URL.

Why this beats buying a list

Verifiable. Every lead has an NPI you can check against the public registry. Bought lists are full of dead and duplicated rows.
Free at the source. The provider data is taxpayer-funded and public; you only pay for the enrichment work.
Segmentable. Taxonomy + geography filtering means you can target "pediatric dentists in Florida" exactly, instead of a generic "healthcare" dump.

Takeaway

The NPI registry solves the "is this a real, licensed provider?" problem for free and at scale. The only thing it's missing is the email — and that's a solvable enrichment step (resolve site, crawl contact pages, keep NPI as the key), not a reason to go buy a stale list. Start from the government data, enrich on top, and every lead in your CRM is one you can trace back to a real identifier.

How to Scrape Emails and Contacts From Any Website (No API Key)

Perufitlife — Fri, 12 Jun 2026 12:22:23 +0000

Most "find emails on a website" tutorials reach for a paid API on the second paragraph. You don't need one. Email addresses, phone numbers and social links are sitting in the public HTML of almost every business site. The hard parts are knowing which pages to fetch, parsing the matches without drowning in false positives, and doing it politely enough that you don't get blocked. This post walks through how to build a no-API-key contact scraper, and where the same logic falls apart at scale.

Why you don't need an API key

A "contact enrichment API" is mostly doing three things on your behalf:

Fetching a handful of pages from the target domain.
Running regex/heuristics over the HTML.
De-duplicating and scoring the results.

All three are things you can do yourself with fetch and a parser. The API's real value is the database it has pre-crawled, plus deliverability verification. For finding the emails a company actually publishes on its own site, you're paying for steps you can run locally.

Step 1: hit the right pages first, not the homepage

The single biggest mistake is scraping only the homepage. Companies almost never put their real contact email on /. They put it on /contact, /about, /team, /imprint, /support, or a footer that links to those.

So the crawl order matters more than the crawl depth. A good heuristic: fetch the homepage, extract internal links, then prioritize any link whose URL or anchor text matches a contact-intent pattern.

const CONTACT_HINTS = /contact|about|team|imprint|impressum|support|help|kontakt|nosotros|equipo/i;

function rankLinks(links, baseUrl) {
  return links
    .filter(href => sameHost(href, baseUrl))
    .sort((a, b) => score(b) - score(a)); // contact-intent pages first
}

function score(href) {
  return CONTACT_HINTS.test(href) ? 10 : 1;
}

Crawling 3-4 ranked pages beats crawling 30 random ones, both for hit-rate and for not hammering the server.

Step 2: extract without the false-positive swamp

The naive email regex matches a lot of junk: image filenames like logo@2x.png, Sentry/analytics keys, version strings. Tighten it and then filter.

const EMAIL_RE = /[a-z0-9._%+\-]+@[a-z0-9.\-]+\.[a-z]{2,}/gi;

function extractEmails(html) {
  const raw = html.match(EMAIL_RE) || [];
  return [...new Set(raw)]
    .filter(e => !/\.(png|jpe?g|gif|webp|svg)$/i.test(e))     // image @2x assets
    .filter(e => !/^[0-9a-f]{8,}@/i.test(e))                  // hashed analytics ids
    .filter(e => !/(sentry|wixpress|example|domain)\.com$/i.test(e));
}

Don't forget obfuscated addresses. Many sites write hello [at] company [dot] com or hide the address behind mailto: only, or split it with @ HTML entities. Decode entities before you run the regex, and add a second pass for the [at]/[dot] pattern.

Phones and socials are the same idea: a permissive regex plus a denylist. For socials, match linkedin.com/company/, twitter.com/, instagram.com/ etc. and strip share-intent URLs (/share?, /sharer).

Step 3: be polite or get blocked

Set a real User-Agent. Default fetch agents get filtered.
Respect a small concurrency cap per host (2-3) and add jitter.
Honor robots.txt for the paths you crawl.
Cache by host so you don't refetch the homepage for every email you want.

Most "the scraper stopped working" reports are really "the scraper got rate-limited because it fired 50 parallel requests with a python-requests UA."

Where the DIY version breaks down

The script above is great for tens of sites. Past that you hit the operational tail:

Concurrency + proxies so one IP doesn't get blocked across thousands of domains.
Retries with backoff for the 10-15% of sites that flake on first request.
JS-rendered contact widgets (some sites inject the email via JavaScript), which need a headless browser only sometimes — running one for every site is wasteful.
Tech-stack detection if you want to segment leads (e.g. "all Shopify stores in this list").

That's exactly the boundary where I stopped maintaining a local script and moved the logic onto a hosted runner. I publish two of them as pay-per-result scrapers on Apify:

Email Scraper & Contact Finder — feed it a list of websites, it does the ranked-crawl + extraction + tech-stack detection described above and returns emails, phones and socials. No API key, no login.
Google Maps Email Extractor — when you don't even have the list of websites yet. Give it a search term + location, it pulls the local businesses from Google Maps (name, address, phone, website, rating) and then runs the contact crawl on each site to get the email. No Google API key.

Both run on Apify's free tier to try, and you pay per result rather than a monthly seat — which is the right shape for lead-gen work that's bursty rather than constant.

Takeaway

For finding the contact details a business publishes about itself, the API-key requirement is mostly artificial. Ranked crawling (contact pages first), a tightened regex with a denylist, entity/obfuscation decoding, and basic politeness get you most of the way. Reach for a hosted runner only when concurrency, proxy rotation and retries become the actual job — which is later than most tutorials would have you believe.

Build a Healthcare Lead List From the Public NPI Registry (NPPES API)

Perufitlife — Fri, 12 Jun 2026 09:52:35 +0000

If you run a marketing agency that serves dentists, dermatologists, med spas, or any medical vertical, you've probably paid way too much for a lead list — and half the rows were stale. Here's the thing almost nobody outside the data world knows: there is a free, official, public registry of every healthcare provider in the United States, and it has a clean API.

It's called NPPES — the National Plan and Provider Enumeration System — and it backs the NPI Registry that CMS (Medicare/Medicaid) maintains. Every provider who bills insurance has an NPI (National Provider Identifier), and the registry is public record.

The free NPPES API

No key, no signup. You hit one endpoint:

https://npiregistry.cms.hhs.gov/api/?version=2.1

It supports filtering by taxonomy (specialty), city, state, and more. Here's a Node example pulling every dentist in Austin, TX:

import got from 'got';

async function searchProviders({ taxonomy, city, state, limit = 200 }) {
  const results = [];
  // API caps each call at 200 results; page with skip
  for (let skip = 0; skip < limit; skip += 200) {
    const { results: page } = await got('https://npiregistry.cms.hhs.gov/api/', {
      searchParams: {
        version: '2.1',
        taxonomy_description: taxonomy, // e.g. "Dentist"
        city,
        state,
        limit: 200,
        skip,
      },
    }).json();

    if (!page || page.length === 0) break;

    for (const p of page) {
      const addr = (p.addresses || []).find(a => a.address_purpose === 'LOCATION') || {};
      results.push({
        npi: p.number,
        providerName: p.basic?.organization_name ||
          `${p.basic?.first_name ?? ''} ${p.basic?.last_name ?? ''}`.trim(),
        specialty: (p.taxonomies?.find(t => t.primary) || {}).desc,
        phone: addr.telephone_number,
        fullAddress: `${addr.address_1 ?? ''}, ${addr.city ?? ''}, ${addr.state ?? ''} ${addr.postal_code ?? ''}`,
      });
    }
  }
  return results;
}

const leads = await searchProviders({ taxonomy: 'Dentist', city: 'Austin', state: 'TX' });
console.log(leads.length, 'providers');

In a few seconds you have name, NPI, specialty, phone, and full address for every dentist in a city — straight from the source of truth, updated as providers re-enumerate with CMS.

The missing piece: email enrichment

The registry gives you a phone and address but no email — that's the gap that makes the raw API only half useful for cold outreach. The fix is a second pass: for each provider, find their practice website (Google/Bing the name + city, or use the listed org URL), then crawl the site's contact and about pages to extract emails, additional phone numbers, social links, and even the tech stack.

That enrichment loop is where the value is. A practice's info@ or front-desk email plus a verified website turns a registry row into an actual lead.

What a finished lead looks like

After the registry pull + website enrichment, each row carries:

npi, providerName, providerType (individual vs organization)
specialty, credential, licenseNumber, licenseState
fullAddress, phone, fax
website, email / emails (all discovered), websitePhones
socialLinks (Facebook, Instagram), techStack, contactPageUrl

The techStack field is a sneaky-good qualifier for agencies: a dentist still on a 2014 template website is a far warmer lead for a web-redesign or paid-ads pitch than one already running a modern stack.

A note on doing this responsibly

The NPI registry is public business-contact data — practice addresses and front-desk lines, not patient data, and nothing HIPAA-covered. Still: respect CAN-SPAM, honor unsubscribes, and target the practice, not individuals' personal info. This is B2B outreach to businesses, full stop.

If you'd rather not build and maintain the registry pagination + website-enrichment crawler yourself, I packaged the whole pipeline into a Healthcare Provider Leads actor — you give it a specialty, city, and state, toggle enrichEmails, optionally set onlyWithEmail, and it returns the enriched rows above, one per provider. But the NPPES API is free and public, so even the DIY version above will get an agency a clean, current vertical list today.

How to Scrape the Facebook Ad Library for Competitor Ad Intelligence (No Login)

Perufitlife — Fri, 12 Jun 2026 09:51:36 +0000

The Facebook (Meta) Ad Library is one of the most underrated datasets in marketing. Because of ad-transparency regulation, Meta is legally required to publish every ad running across Facebook, Instagram, Messenger, and Audience Network — searchable by advertiser, keyword, and country, by anyone, with no account.

That means every competitor's live creative strategy is sitting in a public endpoint. The problem is getting it out cleanly. Let me walk through how the Ad Library actually serves its data and how to scrape it without a Facebook login.

The Ad Library is public — but the data is in XHR, not HTML

Open https://www.facebook.com/ads/library/ and search a brand. The visible page is a React app; the ad cards you see are not in the initial HTML. They arrive via background GraphQL calls (/api/graphql/) that the page fires after load. So a naive fetch + HTML parse gets you almost nothing.

The robust approach is browser-intercept: drive a headless browser to the search URL, let the page make its own signed GraphQL requests, and capture the JSON responses as they come back. The page signs its own requests (tokens, doc IDs, session params), so you ride along instead of trying to forge them.

Intercepting the GraphQL responses

With Playwright, you hook the network layer and grab the responses whose payload contains ad nodes:

import { chromium } from 'playwright';

const ads = [];
const browser = await chromium.launch();
const page = await browser.newPage();

page.on('response', async (res) => {
  const url = res.url();
  if (!url.includes('/api/graphql/')) return;
  const ct = res.headers()['content-type'] || '';
  if (!ct.includes('application/json')) return;

  try {
    const json = await res.json();
    // ad nodes live under search results edges in the GraphQL payload
    const results =
      json?.data?.ad_library_main?.search_results_connection?.edges ?? [];
    for (const edge of results) {
      const node = edge?.node?.collated_results?.[0] ?? edge?.node;
      if (!node) continue;
      const snap = node.snapshot ?? {};
      ads.push({
        adArchiveId: node.ad_archive_id,
        pageName: snap.page_name,
        title: snap.title,
        body: snap.body?.text,
        ctaText: snap.cta_text,
        ctaType: snap.cta_type,
        linkUrl: snap.link_url,
        startDate: node.start_date,
        isActive: node.is_active,
        platforms: node.publisher_platform,
      });
    }
  } catch (_) { /* not the payload we want */ }
});

const q = encodeURIComponent('Nike');
await page.goto(
  `https://www.facebook.com/ads/library/?active_status=all&ad_type=all&country=US&q=${q}`,
  { waitUntil: 'networkidle' }
);
// scroll to trigger pagination, then read `ads`

Scroll the page to trigger more GraphQL pages, dedupe by adArchiveId, and you've got a structured feed of a competitor's entire active ad set.

What you actually get out

The interesting fields for ad spying / competitor research:

Creative: title, body, caption, plus imageUrls / videoUrls for the actual assets
Carousel cards parsed out individually — each card's image, headline, and link
Call-to-action: ctaText ("Shop Now", "Sign Up") and ctaType
Targeting signals: platforms (which of FB/IG/Messenger it runs on), startDate / endDate
Advertiser context: pageName, pageLikeCount, pageCategories
For political/issue ads only (extra transparency): spend, impressions, currency

The gold here is duration + variant count. If a competitor has been running the same creative for three months across five variants, that ad is working — they don't burn budget on losers. You just reverse-engineered their winning hook for free.

Gotchas

Use residential proxies keyed to the country you're querying — the Ad Library is geo-partitioned and datacenter IPs get throttled fast.
GraphQL doc IDs change; that's why intercepting the page's own requests beats hardcoding the query. Let Meta sign it.
Respect the obvious: this is public transparency data, not private user data. Scrape creatives and CTAs, not people.

If you'd rather not maintain the browser-intercept plumbing yourself, I packaged this exact approach into a Facebook Ad Library Scraper — you pass a searchQuery, country, and adType, and it returns the 20+ fields above (including separated carousel cards and spend/impressions for political ads) without any login. Either way, the lesson is the same: the best competitor-ad dataset on the internet is public by law, and you reach it by riding the page's own GraphQL calls.

How to Scrape Public Telegram Channels Without the API, Login, or MTProto

Perufitlife — Fri, 12 Jun 2026 09:51:24 +0000

Most tutorials on scraping Telegram start the same way: register an app at my.telegram.org, get an api_id and api_hash, install a giant MTProto client like Telethon or GramJS, and authenticate with your own phone number. That works, but it has a nasty cost: you are putting a real account on the line. Telegram bans MTProto sessions that look automated, and tying your personal number to a scraper is a great way to lose it.

For public channels, you don't need any of that. There's a much simpler door, and it's been hiding in plain sight: t.me/s/.

The trick: `t.me/s/<channel>`

When you open a public channel in a browser, Telegram normally serves a JS app. But there's a special preview route — the /s/ (for "slug" / preview) path — that returns server-rendered HTML of the channel feed. No JavaScript execution, no login wall, no token.

Try it yourself:

https://t.me/s/durov

That page contains the last ~20 messages as plain HTML, with view counts, timestamps, media URLs, link previews, and forwarded-from info baked right into the markup. You can paginate backwards in time with a ?before=<messageId> query parameter.

Parsing it

Each message lives in a .tgme_widget_message block. Here's a minimal Node example using cheerio:

import got from 'got';
import * as cheerio from 'cheerio';

async function fetchChannel(channel, before = null) {
  const url = before
    ? `https://t.me/s/${channel}?before=${before}`
    : `https://t.me/s/${channel}`;

  const html = await got(url).text();
  const $ = cheerio.load(html);
  const messages = [];

  $('.tgme_widget_message').each((_, el) => {
    const $el = $(el);
    const dataPost = $el.attr('data-post'); // "durov/123"
    const messageId = dataPost ? Number(dataPost.split('/')[1]) : null;

    messages.push({
      messageId,
      text: $el.find('.tgme_widget_message_text').text().trim(),
      date: $el.find('time').attr('datetime'),
      views: $el.find('.tgme_widget_message_views').text().trim(),
      hasMedia: $el.find('.tgme_widget_message_photo_wrap, video').length > 0,
    });
  });

  // oldest message id on this page -> next ?before value
  const oldest = messages.length ? Math.min(...messages.map(m => m.messageId)) : null;
  return { messages, nextBefore: oldest };
}

Loop on nextBefore and you have full backward pagination through the channel's history. Dedupe by messageId and you're done.

Why this beats MTProto for public data

No account at risk. You never log in, so there's nothing to ban.
No rate-limit dance with FLOOD_WAIT. It's just HTTP; rotate IPs if you go heavy.
Stateless and parallelizable. No session files, no auth key persistence.
It's literally the data Telegram chose to make public. The /s/ preview exists so links unfurl nicely on the web — you're reading the same thing a Twitter card preview reads.

The one limitation: this only works for public channels (the ones with a t.me/<name> handle). Private channels and DMs genuinely require MTProto + auth, and that's a good thing.

A reality check on the ecosystem

If you look at existing Telegram scrapers on the Apify Store, the top result has a rating around 1.4 stars — and the reviews all say the same thing: it forces you to hand over your phone number and api credentials, then gets your session limited. People hate it because credential-based scraping of public data is the wrong tool for the job.

That's exactly why I built a Telegram Channel Scraper around the t.me/s/ approach instead. You pass channel handles, it returns structured channel metadata (subscriber count, photo/video/link counters) plus message records with viewCount, date, hasMedia, parsed links, hashtags, linkPreview, and forwardedFrom — no API key, no login, no phone number. It handles the backward pagination, dedupe, and the edge cases (private/nonexistent channels) for you.

But even if you never touch the hosted version, the takeaway stands: for public Telegram data, scrape the web preview, not the API. It's simpler, safer, and it's the data Telegram already decided to publish.

If you build something with the t.me/s/ trick, I'd love to hear what edge cases you hit — the media array parsing (albums vs single photos vs video round messages) is the fun part.

10 free security scanners for the most popular BaaS platforms (2026 edition)

Perufitlife — Mon, 18 May 2026 07:20:52 +0000

10 free security scanners for the most popular BaaS platforms (2026 edition)

If you're shipping on Supabase, Firebase, Strapi, Directus, Payload CMS, Convex, Hasura, PocketBase, Appwrite, or Nhost — you've already trusted your platform to keep customer data private. The fine print is that the platform only enforces the access controls you configured. Forget one row-level rule, one role permission, one access function — and the platform happily serves your users' data to anyone with your public URL.

Across 100+ projects I've audited in the last 12 months:

22% of Supabase projects leak data anonymously through forgotten RLS policies
23% of Firebase projects have firestore.rules with if true or request.auth != null without ownership check
Strapi templates ship with Public-role find enabled on users-permissions/users — exposes every signed-up user
Directus with default Public-role read on directus_users leaks hashed passwords + tokens
WordPress (not BaaS but worth mentioning) exposes /wp-json/wp/v2/users to anonymous callers by default

The fix in every case takes 5-30 minutes once you know what's exposed. The hard part is finding out.

Below are 10 free scanners — one per platform — that probe your project for the most common anonymous-readable patterns and return a verbatim curl an attacker would run + the exact code/admin steps to fix each finding. All run on the Apify free tier (no credit card needed).

1. Supabase RLS Scanner

Probes ~47 common table names via Prefer: count=exact + Range: 0-0 — confirms which tables are anon-readable without ever pulling row data. Returns severity-coded findings (CRITICAL for users, orders, sessions; HIGH for posts, messages). Includes a demo mode (click Run with no input) that scans a real sacrificial Supabase project I maintain so you can see what the report looks like before pasting your own URL + anon key.

2. Firebase Security Auditor

Two-mode probe: provide either projectId (sends anonymous GET to your Firestore REST endpoint to confirm live leaks) or rulesContent (paste your firestore.rules for static analysis catching the 7 most common bad patterns: bare if true, if request.auth != null without ownership, test-mode timestamps, etc.).

3. Strapi Security Scanner

Tries /api/{collection}?pagination[limit]=1 (Strapi v4+) and /{collection}?_limit=1 (Strapi v3) per content-type. Default Strapi templates ship with Public-role find enabled on users-permissions/users — first thing it catches.

4. Directus Security Scanner

Sends /items/{collection}?limit=1&meta=total_count per collection. The two killer findings: directus_users (hashed passwords + tokens) and directus_files (file metadata + signed download URLs).

5. Payload CMS Security Scanner

Tries /api/{collection}?limit=1 per slug. Default templates use access: { read: () => true } on most collections — fine for blog posts, fatal for users/orders/media. Report ships with the exact access.read function rewrite per leaky collection.

6. Convex Security Scanner

POSTs {path: "users:list", args: {}} to your deployment's /api/query endpoint for ~30 common function paths. Convex queries are public by default unless you explicitly call getAuthUserId(ctx) inside the handler.

7. Hasura Security Scanner

GraphQL _aggregate { count } + sample queries against your Hasura endpoint (self-hosted, Hasura Cloud, or any framework on top). The anon role typically inherits SELECT permissions from copy-pasted tutorial examples.

8. PocketBase Security Scanner

GET /api/collections/{name}/records?perPage=1 per collection. PocketBase's API rules look strict on paper, but @request.auth.id != "" only requires "any signed-up user" — which in practice means anyone after a self-serve signup.

9. Appwrite Security Auditor

Sends /v1/databases/{db}/collections/{c}/documents?queries[]=limit(1) with X-Appwrite-Project: <id> header. The any role on read or list exposes every document.

10. Nhost Security Scanner

GraphQL probe against your Nhost project's Hasura endpoint. Specifically targets the anon role permissions Nhost provisions by default — looks for SELECT permissions inherited from Hasura's permissions-tutorial-fixture starter.

How to use the demo modes

Every scanner above ships with a demo mode — click Run with no input, and you'll get back a sample HTML report (Supabase scanner runs a real scan against a sacrificial project I maintain with intentional leaks). Use this to see what a real report looks like before deciding whether to paste your own credentials.

What if you find leaks?

Three options, in order of effort:

Free: Each scanner's HTML report includes paste-ready fix snippets. Drop them into your config/migrations and re-run the scanner.
$29 — I run the scan + write a 1-page summary report + send it to you in 24 hours. For when you want a sanity check without committing further. Stripe.
$99 — I do the fix myself + verify with re-scan, 48-hour turnaround, money-back if I miss anything actionable. Stripe.

There's also a $29/mo continuous monitoring SaaS for the cases where you ship often and want fresh scans every week: rls-monitor.vercel.app.

Why this exists

I'm a solo developer in Lima. I built the @perufitlife/supabase-security CLI in March, then ran it against ~30 random public Supabase projects pulled from GitHub. 22% were leaking user data anonymously. After publishing the npm package, I realized the same RLS-forgetting pattern applies to every BaaS. So I shipped a scanner for each one.

All 10 scanners use the same probe template, scoped per platform's API. The Apify Store layer exists because most developers won't npx something against their production project — but they will click Run on a public Apify actor that runs in someone else's environment.

How to support

If you find any of these useful, the single highest-leverage thing you can do is leave a 30-second review on the Apify Store page. Reviews are the only signal Apify's store ranking algorithm cares about for solo publishers.

Or share this post with someone shipping on a BaaS. Most leaks I find come from teams that never thought to check.

Renzo, solo dev in Lima. Open-source: @perufitlife/supabase-security. 10 Apify scanners. Threads also on dev.to/perufitlife.

I added a $29 tripwire next to my $99 security audit — Hormozi math on solo dev offers

Perufitlife — Mon, 18 May 2026 06:14:10 +0000

I added a $29 "sanity check" tier next to my $99 security audit — here's why solo devs leave money on the table without it

I publish 10 free security scanners on the Apify Store — one for Supabase, Firebase, Strapi, Directus, Payload CMS, Convex, Hasura, PocketBase, Appwrite, and Nhost. Each one ends its HTML report with a CTA to my $99 turnkey-fix service: I do the audit + write the fix + verify it, 48-hour turnaround, money-back if I miss anything actionable.

The funnel ran for 48 hours after I planted those CTAs. Zero clicks.

The scanner traffic wasn't zero — I had a few dozen runs across projects — but nobody clicked through to Stripe. I started asking around in dev Slacks why. Three answers kept coming up:

"I don't have a budget for $99 with no relationship."
"I'd want to talk to you first, but $99 feels too high for a 'is this guy real' kind of message."
"What if you don't find anything? Money-back is fine but I don't want the friction of the refund."

That's the classic gap between "free tool" and "high-commit purchase." There's no middle rung.

So I added one.

The $29 tier

I created a new Stripe payment link: $29 quick scan + 1-page written report in 24 hours. I run the scanner on the customer's project, write up a one-page summary of what's leaking and how to fix it (prioritized), email it within 24 hours, full refund if I find nothing actionable.

Crucially: it does NOT include the fix. That's the $99 tier. The $29 tier is the "is this guy legit" transaction — low enough to be a no-brainer, high enough that it filters out tire-kickers, and high enough that the next sale becomes natural conversation rather than cold pitch.

Stripe link took 90 seconds:

# 1. product
curl -X POST https://api.stripe.com/v1/products   -u $STRIPE_SECRET_KEY:   -d "name=BaaS Security Quick Scan (30min review + report)"

# 2. price
curl -X POST https://api.stripe.com/v1/prices   -u $STRIPE_SECRET_KEY:   -d "product=prod_XXX" -d "unit_amount=2900" -d "currency=usd"

# 3. payment link
curl -X POST https://api.stripe.com/v1/payment_links   -u $STRIPE_SECRET_KEY:   -d "line_items[0][price]=price_XXX" -d "line_items[0][quantity]=1"

Done. Plant the URL in every scanner's HTML report next to the $99 link.

Why solo devs underprice this rung

Most solo devs publishing free tools have one paid offering — usually some flavor of "I'll do it for you" priced at $99-$500. The conversion ladder looks like:

free tool → $99 commitment → ???

That single jump is the killer. The conversion rate from "ran the free tool" to "pays $99" hovers somewhere around 0.5-1% for unknown publishers. Most of the people who would happily pay you $29 to talk to you bounce because the only option is the high-commit one.

The Hormozi-flavored framing: every offer should have a tripwire — a deliberately-low-priced first transaction whose only purpose is to convert a stranger into a customer. The unit economics on the tripwire don't have to make sense in isolation. The tripwire is the gateway to the $99 — and then to the $29/mo recurring subscription, which is where the real money is.

What the numbers should look like

For a free tool with light traffic:

100 free runs → 5 expressed interest → 2-3 buy $29 → 1 of those upgrades to $99 → maybe 1 of those signs up for the $29/mo recurring scan

LTV on that single conversion path: $29 + $99 + ($29 × 6 months avg) = $302 per converted lead.

Without the tripwire, the math is:

100 free runs → 5 expressed interest → 0.5 buy $99 → 0.1 sign up for $29/mo recurring

LTV: $99 × 0.5 + $29 × 6 × 0.1 = $66 per 100 runs.

The tripwire turns the same upstream traffic into ~4.5× revenue. The new offer doesn't even need to be profitable — it just needs to filter and credentialize.

The implementation detail nobody talks about

Adding the $29 link to the HTML report wasn't enough. The order matters. Hormozi calls this the "value ladder." I put the $29 CTA on the left, $99 on the right, color the $29 green (positive/accessible), $99 blue (premium/serious), and let the customer feel the choice.

<a class="cta cta-tripwire" href=".../buy/00w4gz9TWef0">
  $29 — Quick scan + 24h report
</a>
<a class="cta cta-primary" href=".../buy/00w9AT9TWdaW">
  $99 — Full audit + permission rewrites (48h, money-back)
</a>

Two CTAs, side by side. The visitor's gaze finds the $29 first and the comparison happens automatically. Most either click $29 (lower friction) or upgrade themselves to $99 by reading the higher-value description.

Try it on your own project

If you ship on Supabase, Firebase, Strapi, Directus, Payload CMS, Convex, Hasura, PocketBase, Appwrite, or Nhost — run my scanner on your project. It's free, 30 seconds, and uses a demo mode if you'd rather see what the report looks like before pasting your own keys.

All 10 scanners: apify.com/renzomacar
Open-source CLI for Supabase: @perufitlife/supabase-security
$29 quick scan: stripe
$99 turnkey audit: stripe

If the tripwire approach lands, I'll write a follow-up in 30 days with the actual conversion numbers — the published math, not the textbook one.

Renzo, solo developer in Lima, Peru. Building supabase-security, 10 Apify security scanners, and other things at the intersection of "I should automate this" and "let me ship it as a product."

If this resonated, a follow on dev.to helps a solo dev keep shipping. Or just leave a review on any of the 10 scanners — reviews are the single biggest lever a new Apify publisher has.

I shipped 8 BaaS security scanners on Apify in 9 days — the single-file pattern that made it possible

Perufitlife — Mon, 18 May 2026 04:29:34 +0000

I shipped 8 BaaS security scanners on Apify in 9 days — here's the pattern that lets one developer compete with bigger publishers

Two weeks ago I noticed that the Apify Store had zero security scanners for any of the popular Backend-as-a-Service platforms. Not one. Search for "supabase security" or "firebase security" or "strapi security" and the results were a mix of unrelated scrapers and outdated forks.

The market gap was screaming at me. Every BaaS makes the same architectural promise: "your data is private because we have role-based access control." And every BaaS makes the same operational mistake: most developers leave at least one collection or table readable to anonymous users in production.

Across 100+ projects I've audited:

22% of Supabase projects leak data anonymously (RLS forgotten on at least one table)
23% of Firebase projects have firestore.rules with if true or expired test-mode rules
Strapi templates ship with Public-role find enabled — the warning to disable is rarely seen
Directus Public-role read on directus_users exposes hashed passwords and tokens
PocketBase, Appwrite, Nhost, Payload CMS — same story, different syntax

So I built a scanner for each one. Eight in nine days. All public on Apify. All free to run. Each one converts to a $99 turnkey "I'll fix it for you" service that I do off-platform via Stripe.

Here's the pattern that let me ship that fast.

The single-file scanner template

Every BaaS exposes a public REST endpoint per collection/table. The probe is always the same shape:

async function probe(url, collection) {
  const probeUrl = `${url}/<api-path>/${encodeURIComponent(collection)}?<limit-1-param>`;
  try {
    const r = await fetch(probeUrl, { signal: AbortSignal.timeout(8000) });
    if (r.status === 200) {
      const j = await r.json();
      const total = extractTotal(j);                    // varies per BaaS
      const sampleCols = extractSampleColumns(j);       // varies per BaaS
      return { exists: true, readable: true, total, sampleCols };
    }
    if (r.status === 403 || r.status === 401) return { exists: true, readable: false };
    return { exists: false };
  } catch (e) {
    return { exists: false, error: e.message };
  }
}

The differences per BaaS are surgical:

BaaS	API path	Limit param	Count source
Supabase	`/rest/v1/{table}`	`Range: 0-0` (header) + `Prefer: count=exact`	`Content-Range` header
Strapi v4+	`/api/{collection}`	`pagination[limit]=1`	`meta.pagination.total`
Strapi v3	`/{collection}`	`_limit=1`	`data.length` (no total)
Directus	`/items/{collection}`	`limit=1&meta=total_count`	`meta.total_count`
Payload CMS	`/api/{collection}`	`limit=1`	`totalDocs`
PocketBase	`/api/collections/{name}/records`	`perPage=1`	`totalItems`
Nhost (Hasura)	POST `/v1/graphql`	`_aggregate { count }`	`data.X_aggregate.aggregate.count`
Appwrite	`/v1/databases/{db}/collections/{c}/documents`	`?limit=1` + `X-Appwrite-Project` header	`total`
Firebase Firestore	`/v1/projects/{p}/databases/(default)/documents/{c}`	`pageSize=1`	(returns docs directly)

That's it. Same shape, 60-90 minutes to write the next one once the first is done.

The leverage: shared HTML report renderer + CTAs

Each scanner produces JSON dataset rows AND an HTML report saved to the run's key-value store. Same HTML renderer, parameterized per BaaS. Each report ends with:

Severity-color-coded findings table (critical/high/medium/low)
curl reproducer per finding — the exact request an attacker would make
Paste-ready fix code specific to the BaaS (SQL ALTER TABLE ENABLE ROW LEVEL SECURITY, or rules-file diff, or admin-panel click path)
CTAs: turnkey $99 fix offer, $29/mo continuous auto-scans, and the open-source CLI

Every report ends with: "Solo dev competing with bigger publishers — a 30-second review on Apify is the single thing that lifts ranking. Thank you." That last line is what makes reviews actually happen.

The "demo mode" trick that 10x'd conversion

Apify Store visitors hit the actor page, see the input fields, and bounce 80% of the time when they realize they need to paste in their project URL + an anon key just to see what the report looks like.

The fix: remove required from the input schema and add a demo branch at the top of main.js:

if (!supabaseUrl || !anonKey) {
  console.log('🎬 DEMO MODE: No project URL/key provided. Generating sample report.');
  const demoReport = { /* hardcoded plausible findings */ };
  // ... render HTML with a yellow "DEMO" banner up top
  return;
}

Now anyone can hit "Run" with zero input and immediately see what a real scan returns — with full severity table, sample sensitive columns, copy-pasteable fix snippets, and CTAs. The Run button always succeeds and always educates.

This single change made the actor genuinely viral-able. You can paste the actor URL in a Slack/Discord/forum and the recipient gets value in 3 seconds without any commitment.

The 8 actors

Each one is the only scanner of its kind in the Apify DEVELOPER_TOOLS category as of today. That's the whole point — competing on undefended ground.

What's next

I'm building Convex and Xata scanners next. After that I'll likely stop adding new ones and focus on:

One blog post per BaaS showing a real (anonymized) leak I found in the wild
GitHub code-search outreach — F5Bot alerts me when someone commits an anon key in public; I send them the scanner link
A "BaaS leak registry" open-source page indexing known-bad patterns per platform

If you build on any of these BaaS, run the scanner on your own project. The demo mode means you can see the report shape first. Most projects don't leak, but the 22% that do mostly don't know yet.

If you publish to Apify Store yourself: the demo mode pattern is a free 10x to your run-button conversion. Took me too long to figure out — saving the next person that time.

Renzo, solo developer in Lima, Peru. I scan, write, and ship security tools at the intersection of "I should automate this" and "let me publish it as a product." Open source: @perufitlife/supabase-security.

If you found this useful, a follow on dev.to helps a solo developer keep shipping. Or just leave a review on any of the 8 scanners — reviews are the single biggest lever a new Apify publisher has.

DEV Community: Perufitlife

Free open-source security auditors for Supabase, Strapi, Hasura, Convex, Ollama & more

Want me to run one for you — free?

I gave my AI agent live aviation weather — building a free Aviation MCP server

Why MCP, and why this was easy

Connect it

Try it / source

Build a Lead-Gen Automation in n8n: Scrape, Enrich, Export

The pipeline at a glance

Prerequisites

Step 1 - Add the Apify credential

Step 2 - Scrape businesses from Google Maps

Step 3 - Enrich each business with emails

Step 4 - Merge and export to Google Sheets

Step 5 - Put it on a schedule

Why split scrape and enrich into two actors?

Wrap-up

How to Scrape Google Maps Leads in n8n Without Code (Emails + Phones)

What you'll build

Step 1 - Get an Apify token

Step 2 - Add the Apify credential in n8n

Step 3 - Point the node at the Google Maps actor

Step 4 - Send the leads to Google Sheets

Step 5 (optional) - Email the list to yourself

Make it run on autopilot

Why the node-based approach beats DIY scraping

Wrap-up

Healthcare Lead Generation With the Free NPI Registry (and How to Add the Missing Emails)

What the NPI registry actually is

Pulling a target segment

The missing piece: emails

Why this beats buying a list

Takeaway

How to Scrape Emails and Contacts From Any Website (No API Key)

Why you don't need an API key

Step 1: hit the right pages first, not the homepage

Step 2: extract without the false-positive swamp

Step 3: be polite or get blocked

Where the DIY version breaks down

Takeaway

Build a Healthcare Lead List From the Public NPI Registry (NPPES API)

The free NPPES API

The missing piece: email enrichment

What a finished lead looks like

A note on doing this responsibly

How to Scrape the Facebook Ad Library for Competitor Ad Intelligence (No Login)

The Ad Library is public — but the data is in XHR, not HTML

Intercepting the GraphQL responses

What you actually get out

Gotchas

How to Scrape Public Telegram Channels Without the API, Login, or MTProto

The trick: t.me/s/<channel>

Parsing it

Why this beats MTProto for public data

A reality check on the ecosystem

10 free security scanners for the most popular BaaS platforms (2026 edition)

10 free security scanners for the most popular BaaS platforms (2026 edition)

1. Supabase RLS Scanner

2. Firebase Security Auditor

3. Strapi Security Scanner

4. Directus Security Scanner

5. Payload CMS Security Scanner

6. Convex Security Scanner

7. Hasura Security Scanner

8. PocketBase Security Scanner

9. Appwrite Security Auditor

10. Nhost Security Scanner

How to use the demo modes

What if you find leaks?

Why this exists

How to support

I added a $29 tripwire next to my $99 security audit — Hormozi math on solo dev offers

I added a $29 "sanity check" tier next to my $99 security audit — here's why solo devs leave money on the table without it

The $29 tier

Why solo devs underprice this rung

What the numbers should look like

The implementation detail nobody talks about

Try it on your own project

I shipped 8 BaaS security scanners on Apify in 9 days — the single-file pattern that made it possible

I shipped 8 BaaS security scanners on Apify in 9 days — here's the pattern that lets one developer compete with bigger publishers

The trick: `t.me/s/<channel>`