Cloudflare's "Autoconfig" Bot Quietly Broke My Static Site's Deploy — Here's What Happened

A few days ago, Cloudflare's cloudflare-workers-and-pages[bot] opened a pull request on Bracketly's repo, titled "Add Cloudflare Workers configuration." It sat there unmerged while I worked on other things. Today I merged it without thinking too hard about it — it's from Cloudflare's own bot, on a project already hosted on Cloudflare Pages, seemed safe enough.

It took the site down.

What the PR actually did

It added the @astrojs/cloudflare adapter to astro.config.mjs, generated a wrangler.jsonc, and updated package.json. The framing in the PR description is "configures your project for Cloudflare Workers deployment," which sounds like a reasonable modernization — Workers is Cloudflare's newer, more capable runtime.

The problem: Bracketly is a 100% static, client-side site. Every "tool" on it (JSON formatter, Base64 encoder, hash generator, etc.) runs entirely in the browser — there was never a server-rendering need to justify a Workers adapter in the first place.

Adding the adapter restructured the build output. Before: a flat dist/ with index.html at the root, exactly what a plain static-file deploy expects. After: dist/client/ (the actual site) and dist/server/ (a Workers runtime bundle), because the adapter assumes you want on-demand server rendering alongside static assets.

Why it "succeeded" while actually being broken

My existing GitHub Actions deploy step ran wrangler pages deploy dist — the same command that had worked for weeks. It reported success. The build succeeded. The deploy step reported "Deployment complete." Every automated signal said everything was fine.

Wrangler had actually detected the new dist/client/wrangler.json and silently redirected the deploy target from dist to dist/client on its own — a "helpful" auto-detection feature that meant the command exit code was misleading. It genuinely uploaded files and genuinely returned success. It just wasn't obviously communicating that the actual site paths (/, /tools/whatever, the sitemap) were now 404ing.

I only caught it because I happened to run a manual curl against the live homepage right after the merge and got nothing back where a title tag should be.

The fix

git revert -m 1 <merge-commit>, rebuild locally to confirm dist/index.html exists again (not nested), push. Total downtime: a few minutes, only because I was actively watching for it.

The actual lesson

Automated "helpful" configuration bots — especially ones with commit/PR access to your deploy pipeline — don't know your project's actual architecture. This one assumed "Cloudflare Pages project" implies "wants Workers/SSR," which is a reasonable default guess but was flatly wrong for a purely static site. A green checkmark on a CI deploy step is not the same thing as "the site actually works" — it just means the command didn't throw a non-zero exit code. Worth an actual curl against production after any deploy-pipeline change, automated or not, regardless of how official-looking the bot that proposed it is.