DEV Community: CodeLong888

My deploy agent could have dropped my database and I didn't realize

CodeLong888 — Mon, 22 Jun 2026 15:28:56 +0000

I run a small free privacy-tools site as a side project. The product was fine. The maintenance was the part that wore me down: SEO upkeep, structured data, keeping every page linked. So I built a scheduled agent to handle it.

It's a Claude agent that runs a few times a day. It reads the current state of the site, picks one small improvement, ships it to production, and sends me a digest of what it changed. Most runs are boring: a meta description here, a schema fix there.

One run, it caught something I didn't know about. I'd shipped a handful of tools that were never actually listed in my own directory. They worked if you had the direct link, but nothing pointed to them, so neither Google nor any AI assistant could find them. The agent surfaced them, rebuilt the catalog into machine-readable structured data, and fixed it on its own.

I was pleased with that, so I posted about it. The pushback was immediate, and most of it was fair.

The objections that actually landed:

The digest is the agent describing what it thinks it did. It is not a receipt. If something ships three times a day, you want the real diff and deploy log, captured outside the agent, not the agent's own summary of its own work. An LLM grading its own homework is exactly what you shouldn't trust.

A scheduled, autonomous agent turns time into an attack surface. Nobody has to attack you live. They leave something in whatever the agent reads next, and the schedule does the rest while you sleep.

Nothing stops an LLM from deciding that DROP TABLE is a reasonable improvement. It has no instinct that deleting data is bad. It can talk itself into a destructive change as easily as a helpful one.

Blast radius. This is survivable if you run small isolated services where one bad change is contained. It is a different story on a single app where one deploy touches everything.

So I stopped feeling clever and went to look at what my agent could actually do. Not what I had told it to do in its instructions, what its permissions physically allowed. The answer was bad. It could run arbitrary commands, deploy and delete the whole service, run destructive database operations, and force-push over my git history. My entire safety story was one line in a prompt that said "additive changes only." That is not a guardrail. If the agent had ever decided dropping a table was an improvement, nothing in the system would have stopped it.

That is the lesson I actually paid for: convention is not a guardrail. "I told it not to" is not the same as "it cannot."

What I changed:

I scoped the permissions so it cannot, instead of trusting it not to. A tight allow-list (deploy only) plus a hard deny-list: no destructive database commands, no delete, no force-push, no rm, no arbitrary execution. Even if the agent convinces itself, the command fails.

I stopped treating the digest as the source of truth. The real record is the diff and the deploy log, captured independently of the agent.

I put a literal blocklist on the load-bearing paths: auth, billing, anything that is not additive content.

I now treat anything the agent fetches from an external site as data, never as instructions. That closes the leave-something-it-reads-and-wait angle.

The last piece, still open: the token it deploys with is a full-access login. Scoping it to the minimum is the final wall, so a slipped command hits a permission error instead of my infrastructure.

I still think letting an agent ship to production is worth it. But the safety has to live in what it physically cannot do, not in what you politely asked it to avoid. The most useful part of the whole thing was not my agent catching a bug. It was a pile of strangers catching my agent.

How llms.txt made ChatGPT my #1 traffic source (a free IP API, 8 weeks in) Tags: webdev, seo, ai, cloudflare

CodeLong888 — Mon, 15 Jun 2026 06:52:27 +0000

I run HackMyIP, a free IP/privacy toolkit: IP lookup, VPN/proxy and DNS-leak detection, email-breach check, WHOIS, a CIDR calculator, and a free no-key API. It's about 8 weeks old. I'm writing this up because one decision moved the needle more than any backlink or keyword I chased: I made the site readable by AI assistants, not just by Google.

Here's the part that surprised me. Looking at the last 28 days of analytics:

chatgpt.com referrals: 157 sessions (107 of them engaged)
Google search: 44 sessions

That's roughly 3.5x more real traffic from ChatGPT than from Google. For a small, young site with thin domain authority, that ratio is not what I expected, and it's almost entirely because of a few small files most SEO guides never mention.

What I actually shipped

Three AEO ("Answer Engine Optimization") surfaces, all static, all boring to build:

/llms.txt — a markdown index of the site written for an LLM: a one-line summary, the questions the site answers, and a categorized list of every tool with a one-line description and URL. Think of it as a sitemap that reads like documentation instead of XML.
/llms-full.txt — the expanded version with more detail per tool, for assistants that will read a longer file.
An OpenAPI 3.1 spec + an ai-plugin.json manifest under /.well-known/, so an assistant (or a plugin runtime) can discover the API and the exact endpoints programmatically.

The API itself is the thing those files point at: 10 endpoints, no key, no signup, JSON responses, CORS enabled (Access-Control-Allow-Origin: *). For example, GET /api/ip returns your IP plus geolocation, ASN/ISP, and a privacy classification:

{
  "success": true,
  "data": {
    "ip": "…",
    "location": { "city": "…", "region": "…", "country": "…", "timezone": "…" },
    "network": { "asn": 3462, "isp": "…", "tls_version": "TLSv1.3" },
    "privacy": { "type": "residential", "score": 90, "grade": "A", "is_vpn": false, "is_datacenter": false }
  }
}

Why this works (my best read of it)

When someone asks ChatGPT "what's a free IP lookup API with no key?" or "how do I test if my VPN is leaking DNS?", the assistant needs a citable, machine-readable source. A normal marketing page buries the answer in layout and JS. An llms.txt hands the assistant exactly what it needs: here are the tools, here's what each does, here are the URLs. The OpenAPI spec does the same for the API. You're not gaming a ranking. You're lowering the cost for an assistant to recommend you accurately.

Two things I'd stress if you try this:

Be honest in the file. Every claim in my llms.txt is something the site actually does. If an assistant cites you and you don't deliver, that's worse than not being cited. (My API really is keyless; my leak tests really run client-side.)
It compounds with usefulness, not instead of it. llms.txt didn't create the tools. It made the existing useful tools discoverable to a new class of referrer. If the underlying thing isn't genuinely good, an index of it won't help.

What I'd do the same again

Write llms.txt by hand, structured by user-intent ("questions this site answers") not by your internal nav.
Ship a real OpenAPI spec if you have any API at all. It's the difference between "a site with an API" and "an API an assistant can call."
Keep it current. A stale index that lists tools you removed is a trust leak.

I'm not claiming llms.txt is magic. 8 weeks of data on one small site is a single data point, and "direct" traffic is noisy. But the chatgpt-vs-google gap has been consistent enough that I now treat AI-discoverability as a first-class channel, not an afterthought. If you've got a developer tool or an API and you've only optimized for Google, you're probably leaving your fastest-growing referrer on the table.

Files are live if you want to see the format: llms.txt · the API.

I Built a Free Meme API with 2,300+ Templates on Cloudflare Workers

CodeLong888 — Sun, 17 May 2026 05:24:11 +0000

Last month I wanted to add meme generation to a side project. Every meme API I found was either paid, rate-limited to hell, or had maybe 50 templates.

So I built my own. justmeme.wtf has 2,300+ meme templates, a free API, and runs entirely on Cloudflare Workers + D1.

Here's how it works and what I learned.

The Stack

Cloudflare Workers — handles all routing, SSR, and image generation
Cloudflare D1 — stores 2,300+ meme templates with metadata
Canvas API — server-side text rendering on meme images
No framework — vanilla JS, single index.js file

Total monthly cost: $0 (Cloudflare free tier covers it).

The API

The API is completely free, no auth required. Here's what you can do:

Get all templates

curl https://justmeme.wtf/api/v1/templates

Returns every template with its slug, name, text box count, and dimensions.

Get a specific template

curl https://justmeme.wtf/api/v1/templates/drake-hotline-bling

Returns template details including image URL and text box positions.

Search templates

curl "https://justmeme.wtf/api/v1/templates/search?q=brain"

AI meme generation

curl -X POST https://justmeme.wtf/api/v1/ai-generate -H "Content-Type: application/json" -d '{"prompt":"a cat coding"}'

Full API docs: justmeme.wtf/api-docs

Architecture Decisions

Why Cloudflare Workers?

I wanted zero cold starts and global edge deployment without managing servers. Workers spin up in less than 1ms and run in 300+ locations. For an image API that needs to be fast, this matters.

Why D1 over KV?

KV is great for simple key-value lookups, but I needed to query templates by category, search by name, and paginate results. D1 gives me SQL for free.

Image generation without Node Canvas

The tricky part was rendering text on images without node-canvas (which doesn't work in Workers). I used the built-in Canvas API available in Cloudflare Workers with the Browser Rendering binding. For simpler cases, I pre-compute text positions and overlay them on the fly.

SEO: Making Memes Indexable

Each of the 2,300+ templates has its own page at /meme/{slug} with:

Unique title and meta description (not just the template name)
Schema.org structured data
OG image that's the actual meme template
How-to content for each template
Related templates for internal linking

The sitemap splits across multiple files to stay under the 50MB limit.

What I'd Do Differently

Start with fewer templates. I loaded 2,300 on day one. Google flagged a lot as "discovered but not indexed" because the pages looked too similar. Starting with 200 high-quality pages and growing would have been smarter.
Add user-generated content earlier. Google values pages that change. A comment section or "trending memes made with this template" would help.
Build the API first. The website gets traffic, but the API is what developers actually link to. I should have launched the API on its own and marketed it to dev communities.

Try It

Website: justmeme.wtf
GitHub: JustMeme-wtf/justmeme-api
API docs: justmeme.wtf/api-docs
Make a meme in 10 seconds: justmeme.wtf

The whole thing is a Cloudflare Worker. If you're building something that needs meme generation, the API is free. Use it.

How to Check for Email Breaches Programmatically (Free API, No Key)

CodeLong888 — Tue, 21 Apr 2026 20:00:23 +0000

The Problem

You're building an app and need to warn users if their email has been compromised in a data breach. The options are:

HaveIBeenPwned API: Requires a paid API key ($3.50/month)
Build your own: You'd need to aggregate breach databases yourself
HackMyIP Breach API: Free, no key, JSON response

I built the third option. Here's how to use it.

Quick Start

curl "https://hackmyip.com/api/breach?email=test@example.com"

Response:

{
  "success": true,
  "data": {
    "email": "tes***@example.com",
    "breaches": 13,
    "services": ["Adobe", "Canva", "LinkedIn", "Dropbox", ...],
    "risk": {
      "score": 71,
      "level": "high"
    },
    "passwords": {
      "plain_text": 3,
      "weak_hash": 2,
      "strong_hash": 5,
      "total": 10
    }
  }
}

No API key. No signup. No rate limits for reasonable use.

JavaScript Example

async function checkBreach(email) {
  const response = await fetch(
    `https://hackmyip.com/api/breach?email=${encodeURIComponent(email)}`
  );
  const { data } = await response.json();

  if (data.breaches > 0) {
    console.log(`⚠️ Found in ${data.breaches} breaches!`);
    console.log(`Risk level: ${data.risk.level}`);
    console.log(`Affected services: ${data.services.join(', ')}`);

    if (data.passwords?.plain_text > 0) {
      console.log(`🚨 ${data.passwords.plain_text} passwords stored in plain text!`);
    }
  } else {
    console.log('✅ No breaches found');
  }
}

checkBreach('user@example.com');

Python Example

import requests

def check_breach(email):
    resp = requests.get(f"https://hackmyip.com/api/breach?email={email}")
    data = resp.json()["data"]

    print(f"Breaches: {data['breaches']}")
    print(f"Risk: {data['risk']['level']} ({data['risk']['score']}/100)")

    if data["passwords"]:
        print(f"Plain text passwords: {data['passwords']['plain_text']}")

    return data

check_breach("user@example.com")

All Available Endpoints

HackMyIP isn't just breach checking. It's a full privacy API:

Endpoint	Description	Auth
`GET /api/breach?email=x`	Email breach check (500+ databases)	None
`GET /api/ip`	Your IP + geolocation + VPN detection + privacy score	None
`GET /api/lookup?ip=x`	Look up any IP address	None
`GET /api/score`	IP cleanliness grade (A-D) + VPN detection	None

All endpoints return JSON with CORS enabled. Use from any domain.

Comparison with Alternatives

Feature	HackMyIP	HaveIBeenPwned	LeakCheck
Price	Free	$3.50/month	Freemium
API Key Required	No	Yes	Yes
Breach Check	✅	✅	✅
Risk Scoring	✅	❌	❌
Password Analysis	✅	❌	✅
IP Geolocation	✅	❌	❌
VPN Detection	✅	❌	❌
Privacy Score	✅	❌	❌
CORS	✅	❌	❌

npm Package

npm install hackmyip

const { checkBreach, getMyIP, getPrivacyScore } = require('hackmyip');

const breach = await checkBreach('user@example.com');
const ip = await getMyIP();
const score = await getPrivacyScore();

Use Cases

User registration: Check if a new user's email has been compromised and suggest a password change
Security dashboards: Display breach status for monitored accounts
Compliance tools: Verify employee email exposure
Personal projects: Build your own "Have I Been Pwned" checker
CLI tools: Quick breach checks from the terminal