DEV Community: 彭勇

I built a free image upscaler on Cloudflare Workers — here's what bit me

彭勇 — Thu, 17 Sep 2026 15:52:45 +0000

I kept running into the same annoyance: screenshots that arrive looking like LEGO, photos that get crushed by messaging apps, and every "fix" behind a signup wall or a subscription. So I built unpixelate.net — upload a pixelated or blurry image, get a sharper one back in seconds. No account, no credit card.

This post isn't a product tour. It's the stuff that actually cost me debugging time: an AI inference API with three hidden traps, a math bug that would have made my own marketing a lie, and a storage quirk where a legal promise ("we delete your images") can silently die while everything returns HTTP 200.

The stack

Next.js 16 (App Router) on Cloudflare Workers via @opennextjs/cloudflare
R2 for image storage (zero egress fees — this matters later)
D1 for billing state, because credits need transactions
Replicate for inference: prunaai/p-image-upscale as the workhorse, Topaz's image-upscale as the paid HD engine
Zero runtime dependencies in the integration layer — the Replicate client and the AWS SigV4 implementation are both hand-rolled on fetch and node:crypto

Why no SDK for Replicate? The client is ~200 lines, and I wanted every header and timeout visible in code review rather than buried in a dependency. This turned out to be the right call, for reasons you'll see.

Trap #1: three things the Replicate docs make non-obvious

A naive client "works" in testing and then fails in production in three separate ways.

1. POST /v1/predictions has no model field. The owner/name shorthand only works for official Replicate models, through a different endpoint. For community models you must send the full 64-character version id. Pin it, and expose a resolveLatestVersion() helper so drift is visible instead of silent:

const created = await fetch("https://api.replicate.com/v1/predictions", {
  method: "POST",
  headers: {
    authorization: `Bearer ${token}`,
    "content-type": "application/json",
    // Blocks for up to 60s server-side — usually returns a finished
    // prediction and the polling loop never runs.
    prefer: "wait=60",
    // Bounds what we're billed for if this process dies mid-prediction.
    // The API enforces a 5s floor on this header.
    "cancel-after": "300s",
  },
  body: JSON.stringify({ version, input }), // version, NOT model
});

2. Output URLs require your auth header. Results are served from replicate.delivery, and a bare fetch(outputUrl) can 401. Every tutorial forgets this. You must send the same bearer token when downloading the result.

3. Predictions are deleted after about an hour. Inputs, outputs, logs — gone. You cannot store the output URL and fetch it later from a queue consumer. The bytes must be copied somewhere durable during the same request that polls them:

// After the prediction succeeds, immediately pull the bytes down
// with a hard ceiling, then upload to R2 ourselves.
const res = await fetch(outputUrl, {
  headers: { authorization: `Bearer ${token}` },
  signal,
});
const chunks = [];
let size = 0;
for await (const chunk of res.body) {
  size += chunk.length;
  if (size > MAX_DOWNLOAD_BYTES) throw new Error("output over ceiling");
  chunks.push(chunk);
}

That ceiling matters on Workers, where memory is capped and a runaway download shouldn't take the isolate down with it.

Trap #2: the 4-megapixel promise

The marketing page says "up to 4 MP output." Sounds like the model's job, right? Ask for 4 megapixels, ship it.

Wrong. The model has two upscale modes and neither does what the label says. I measured against the live API:

source	mode	asked	got	actual MP	ratio
1400x1050	factor	1.65	2308x1732	3.997	0.9987
1600x900	factor	1.65	2640x1484	3.918	0.9994
1400x1050	target	4	—	4.189	1.0473
1600x900	target	3	—	3.144	1.0480

target mode overshoots by ~4.8%, and its schema is an integer, so you can't trim it with a fractional value — the API rejects that with a 422. factor mode lands within 0.2% of what you asked for. So every viable plan uses factor, computed backwards from the budget:

// Aim 1% under the cap. The model rounds output dimensions, so asking
// for exactly 4 MP can land a fraction ABOVE it — which would make the
// advertised "up to 4 MP" claim false. The headroom is free.
const TARGET_MARGIN = 0.99;

export function planUpscale({ sourceMp, maxOutputMp = 4 }) {
  const budget = maxOutputMp * TARGET_MARGIN;
  const ideal = Math.sqrt(budget / sourceMp);
  const factor = Math.min(8, Math.max(1, Number(ideal.toFixed(2))));
  return { mode: "factor", factor };
}

There's a second, quieter decision in there: if the source is already at or above the cap, we reject before spending the user's credit instead of silently handing back a smaller image than they uploaded. "Your input is too big" is a better answer than a silent downgrade.

The pixel art exception

One more wrinkle in that planner. For most images, inventing detail is the product. For pixel art, inventing detail is always wrong — the art is a grid, and the only correct result is that same grid, larger. But the cap-fitting math happily asks for ~8x on a small sprite, and past roughly 8x the model starts hallucinating pixels.

So callers that know the input is pixel art pass an explicit factor: 4 and get exactly 4x. Small special case, but it's the difference between "this tool gets pixel art" and "this tool ruins pixel art" in a screenshot.

Why everything is PNG (and why R2 makes that free)

The default output format is PNG, deliberately. The model synthesizes pixels; re-encoding those to JPEG throws away detail we just paid for. On most hosts, storing larger files also means paying egress every time someone downloads a result — but R2 charges zero egress, so the bigger file costs storage only. This is one of those architecture decisions that's only obvious in retrospect: the storage pricing shaped the image quality policy.

Trap #3: the privacy promise that dies at HTTP 200

The privacy policy promises uploads and results are deleted after at most 14 days. Enforcing that is a cron that sweeps two R2 prefixes (in/ and out/). Boring code — except for one landmine:

S3's DeleteObjects answers HTTP 200 even when individual keys fail to delete. If you only check the status code, the cron logs "success" every night while a growing pile of expired images survives forever. A legal promise, silently broken, with nothing in the logs.

So the retention function collects every per-key failure instead of throwing on the first one, and the callers decide how to escalate:

// Returns { removed, failed } — never trust the HTTP status alone.
const { removed, failed } = await runRetention({ client, days: 14 });
if (failed.length > 0) process.exitCode = 1; // cron invocation shows as failed

I also merged the prefix list into a single module after noticing the local prune script and the Worker cron each held their own copy. That's the exact shape of bug a legal promise dies from: add a third storage prefix, update one caller, and the other silently stops covering it — with no error anywhere.

What I'd tell my past self

Pin model versions and log version drift. "Latest" is not an API contract.
Measure what the model actually returns, not what the schema says. The table above is 15 minutes of curl that saved the honesty of the landing page.
Anytime a legal promise ("we delete after N days") depends on a cron, simulate a partial failure and check that someone notices.
Zero-dependency integration modules are testable against live APIs with no mocking layer, and on Workers, small is a feature.

Try it

The site is live at unpixelate.net — free to start, no signup, JPG/PNG/WEBP. One honest caveat that's on the site too: the AI estimates missing detail. It's a reconstruction, not a forensic restore — a heavily pixelated face won't come back looking exactly like the real person. For screenshots, compressed photos, and text that went soft, though, the difference is night and day.

If you've shipped AI features on Workers, I'd love to hear what bit you — especially around long-running inference on a platform built for short requests. My current answer is Prefer: wait plus a bounded poll, but I don't love it.

I Built an AI Tool for Editing Text Inside Images

彭勇 — Mon, 07 Sep 2026 14:21:19 +0000

I built EditTextImage, a small AI tool for one specific task: replacing visible text inside an existing image.

The idea came from a familiar annoyance. You have a screenshot, poster, product graphic, or social image that is almost right, but one date, label, price, or typo needs to change. Recreating the asset in Photoshop or another design tool can take much longer than the actual change deserves.

So I wanted to make the workflow deliberately narrow:

Upload an image
Enter the text currently visible
Enter the replacement text
Generate and download the edited result

The goal is not to replace a design workflow. It is to help with small, practical text corrections while keeping the original layout, background, lighting, and typography as close as possible.

What it is useful for

Updating labels or callouts in product screenshots
Correcting dates, times, or sponsor information on posters
Refreshing e-commerce banners and social graphics
Adjusting prices or daily specials on menu boards
Fixing small copy mistakes without recreating an entire image

The editor supports JPG, PNG, and WebP files up to 10 MB. New accounts receive one free credit, and no credit card is required to try it.

A note on the limitations

This is AI-assisted image editing, so it is not magic. Results can need another attempt, especially when text is very small, highly decorative, curved, or tightly integrated with a complex background.

I would rather be clear about that than promise “pixel-perfect” output in every case. The tool works best when the requested change is focused and the original text is readable.

It is also not intended for misleading edits. Please do not use it for government IDs, official documents, currency, copyrighted work you do not own, or any image modification intended to deceive someone.

Why I kept it focused

There are already excellent full-featured image editors. I did not want to build another large creative suite with dozens of controls.

Instead, I wanted to test whether a constrained workflow could reduce the friction of a very common request: “Can we just change this text?”

The product uses AI image editing to handle the visual adjustment, while the interface asks for the original wording and the replacement text to keep the edit specific.

You can try it here: edittextimage.net

I am still improving the result quality and the overall workflow. Honest feedback is especially useful: which image types work well, which ones fail, and what would make this genuinely useful in your day-to-day work?

I Built a Simple Tool to Remove Matcha Filters from Photos

彭勇 — Fri, 14 Aug 2026 13:08:09 +0000

Hi dev.to community,
I recently built a small web tool called Remove Matcha Filter:
https://removematchafilter.org
The idea is simple: many photos look overly green, soft, or tinted after using a “matcha” style filter. This tool helps remove that color cast and bring the image closer to a cleaner, more natural look.

It is still a focused little project, not a huge product. My goal is to make it fast, easy to use, and useful for people who just want their original photo tones back without opening a heavy editing app.

If you have a photo with this kind of greenish filter, feel free to try it here:
👉 Remove Matcha Filter
I’d also appreciate any feedback on the result quality, UI, or wording. Thanks for taking a look.

I Built a Free NBA-Style Player Builder and Season Simulator

彭勇 — Wed, 12 Aug 2026 12:49:34 +0000

I’ve been working on a small basketball web game called Build a Hooper.

You can try it here: https://buildahooper.app/

The idea is simple: instead of just picking one ready-made player, you build your own hooper piece by piece.

You spin historic teams, draft legendary players, take one skill from each of them, and then run your custom player through a full 82-game season simulation.

No signup is required to start playing.

Why I made it

A lot of basketball builder games are fun for a few minutes, but they usually stop at the draft card.

I wanted the build to matter after the picks were done.

So in Build a Hooper, the fun is not only “Can I make a stacked player?” but also:

Does this build actually win games?
Is it balanced enough for a full season?
Did I waste too many picks chasing scoring?
Can this player survive playoff-style pressure?
Would I build the same way next time?

That last part matters. I wanted each run to feel replayable, not solved after one try.

How it works

The main draft flow has 13 skill picks.

Each round gives you a team/player pool. You choose a player, then steal one skill from that player to add to your custom hooper.

After the draft, the site simulates an 82-game season and gives you a result based on the player you built.

There are also different draft modes:

Classic: you can see the ratings and make cleaner decisions.
Blind: ratings are hidden, so you have to trust names, roles, and instinct.
Chaos: the available skill board is limited each round, so you can’t always build the exact player you planned.

Classic is probably the best place to start. Blind and Chaos are more interesting once you already understand the system.

What you can try

If you want the fastest path, start here:

Play Build a Hooper

If you want to understand the rules first:

How to Play

There are also a few extra pages if you want to explore more:

What I’m still improving

This is an independent fan project, and I’m still tuning it.

A few things I’m thinking about:

making the simulation feel more transparent
improving the result page
adding more interesting achievement paths
making the leaderboard more fun to chase
balancing draft choices so there are fewer obvious picks

If you try it and something feels confusing, too easy, too random, or just not fun, I’d genuinely like to hear it.

The site is here:

https://buildahooper.app/

Thanks for checking it out.

I Built a Free Text Repeater Tool for WhatsApp – Here's What I Learned About SEO and Cloudflare Pages Deployment

彭勇 — Tue, 31 Mar 2026 01:26:57 +0000

Why I Built This

A friend kept manually copy-pasting "sorry 🙏" over and over to send dramatic apology messages on WhatsApp. I watched him do it for about 30 seconds before thinking — this is a solved problem.

A few days later, TextRepeater was live.

It lets you type any text, set how many times to repeat it (up to 1000), pick a separator, add emoji scene modes, and apply 15 visual effects — all in the browser, no account, no backend.

The Stack

Deliberately simple:

Next.js 14 with output: 'export' (fully static)
Tailwind CSS for styling
Cloudflare Pages for hosting
GitHub Actions for CI/CD

No database. No API routes. No auth. Everything runs client-side.

Deployment: GitHub Actions + Cloudflare Pages Direct Upload

The interesting part was automating deployment. Cloudflare Pages has a GitHub App integration, but connecting it via API throws a cryptic error:

error code: 8000011 — There is an internal issue with your Cloudflare Pages Git installation.

This happens because the GitHub App OAuth flow requires browser authorization — it can't be done purely through the API.

The workaround: use Direct Upload mode instead of GitHub integration.

Step 1 — Create the Pages project via API (no `source` field)

curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/pages/projects" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "text-repeater",
    "production_branch": "main"
  }'

Step 2 — GitHub Actions workflow

name: Deploy to Cloudflare Pages

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci
      - run: npm run build

      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy out --project-name=text-repeater --branch=main

Every push to main triggers a full build and deploy. Zero manual steps.

Next.js Config for Static Export

For Cloudflare Pages to serve routes correctly:

// next.config.mjs
const nextConfig = {
  output: 'export',
  trailingSlash: true,   // important for Cloudflare routing
  images: {
    unoptimized: true,   // required for static export
  },
}

export default nextConfig

trailingSlash: true is the one that trips people up — without it, direct URL navigation breaks on Cloudflare Pages.

Custom Domain via Cloudflare API

After purchasing the domain, instead of clicking through the dashboard, I wired everything via API:

# 1. Bind domain to Pages project
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/pages/projects/text-repeater/domains" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"name": "textrepeater.top"}'

# 2. Add CNAME record (proxied = orange cloud enabled)
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "CNAME",
    "name": "textrepeater.top",
    "content": "text-repeater-9lr.pages.dev",
    "proxied": true
  }'

SSL certificate issued automatically within ~2 minutes.

SEO for a Static Next.js Site

Launching a new domain means starting from zero authority. Here's what I set up on day one:

1. Canonical URLs (every page)

export const metadata: Metadata = {
  alternates: {
    canonical: 'https://textrepeater.top/apology-mode/',
  },
}

Without this, search engines might treat http vs https or trailing slash variants as duplicate pages, splitting your ranking signal.

2. robots.txt

User-agent: *
Allow: /

Sitemap: https://textrepeater.top/sitemap.xml

Obvious but easy to forget on a static site.

3. sitemap.xml with lastmod

<url>
  <loc>https://textrepeater.top/</loc>
  <lastmod>2026-03-30</lastmod>
  <changefreq>weekly</changefreq>
  <priority>1.0</priority>
</url>

4. Open Graph + Twitter Card

openGraph: {
  type: 'website',
  siteName: 'TextRepeater',
  url: 'https://textrepeater.top',
  title: 'Text Repeater Online — Repeat Any Text Instantly',
  description: '...',
},
twitter: {
  card: 'summary',
  title: 'Text Repeater Online — Repeat Any Text Instantly',
  description: '...',
},

5. JSON-LD Structured Data

For the homepage:

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify({
      '@context': 'https://schema.org',
      '@type': 'WebSite',
      name: 'TextRepeater',
      url: 'https://textrepeater.top',
    }),
  }}
/>

For tool pages, use WebApplication with offers.price: '0' — this can show a free badge in rich results.

The "Scene Mode" Idea

The differentiator I'm most proud of is Scene Modes — instead of just repeating text, you pick a context (apology, birthday, anger) and the tool automatically inserts themed emoji patterns throughout your message.

Input:  "I'm really sorry"
Output: "🙏 I'm really sorry 😔 I'm really sorry 💦 I'm really sorry 🥺"

It maps to specific long-tail keywords like "apology text generator" and "sorry message generator for WhatsApp" — much lower competition than "text repeater" alone.

Each Scene Mode is its own page with targeted metadata, giving the site multiple entry points for organic traffic.

What's Next

Completing the remaining Scene Modes (Heart, Anger, Birthday, Like)
Adding more WhatsApp-specific templates
Tracking which visual effects actually get used

Try It

textrepeater.top — free, no sign-up, works on mobile.

If you're building something similar (static Next.js + Cloudflare Pages), the Direct Upload + GitHub Actions approach is the smoothest path I've found. Happy to answer questions in the comments.