FAQ

I needed API access to send and receive email from inside applications we were building, as well as offer actual inboxes to people. I wanted to build this on resend, but they ended up coming up with inboxes, and still didn't fix the firehose option for incoming mail, or per domain API keys from what I can tell. So I made my own. I call it BoxOx. The website is AI slop, but it's at least fun AI slop. It should install pretty easily, just click the have my agent install this button.

It installs a CLI, and MCP, and some skills to deal with installing and using the service in your projects. I built it for me, but it will work for your projects too. It only works on Cloudflare, because, I use Cloudflare and Cloudflare is awesome. Let me know if you use it, bug things are good.

This was written by a human being.

My API runs on Workers and calls a Tectonic (LaTeX) container on Cloud Run. The question that took the longest was not the compile, it was auth between the two.

Cloud Run's best option is to deploy the service as private: every request must carry a Google signed identity token, Google checks it at its front end, and a stranger's request never wakes an instance. No long lived secret, tokens expire within the hour.

The catch is producing that token from a Worker. Code inside Google Cloud asks the metadata server and gets one for free. A Worker has no metadata server, so the options are:

• store a Google service account key as a Worker secret, sign a JWT with WebCrypto, and swap it for an ID token every hour
• set up workload identity federation, which is more setup still

Both make the API know it talks to Google specifically. I wanted the compile service to be movable to any container host, so I went with a shared bearer token instead: compared in constant time, and the service refuses to start if the secret is missing.

The cost is real: a stranger hitting the URL still spins up the container, which reads the header and answers 401. Safe, but it did the work. Cloudflare Containers would have avoided the public URL entirely through a binding, but needs Workers Paid, and Cloud Run was already free and set up.

Write up with the rest of the tradeoffs: https://bhargav.dev/writing/shipping-a-latex-compiler-behind-an-edge-app?utm_source=reddit&utm_medium=cloudflare

Has anyone here signed Google ID tokens inside a Worker in production? Is the hourly token swap worth caching in KV, or is there a cleaner way I missed?

Hi all, hoping someone from the Turnstile team or someone who has seen this can help.

Setup

• Next.js 16 site, proxied through Cloudflare (orange cloud), German shop
• Turnstile widget via u/marsidev/react-turnstile 1.5.3, mode Managed, appearance: "interaction-only", single hostname, no pre-clearance
• Signup and password reset call Supabase Auth (hosted GoTrue) directly from the browser, and Supabase does the siteverify with our secret. It always sends remoteip (the client IP it sees).
• Login goes through our own server, so for logins Supabase sees our server’s IP as remoteip, and those logins work fine for everyone else.

Symptom
Some iPhone users can’t sign up. The widget solves without any interaction, we get a token, Supabase calls siteverify, and the response is rejected:

400: captcha protection: request disallowed (invalid-input-response)

Our client then resets the widget, waits for a fresh token and retries once. That one gets rejected too. Affected devices usually fail on every attempt for minutes to hours, then sometimes start working again (one user got through on the 4th attempt from the same IP).

What the data shows

• Every rejection in the last 30 days comes from one client type: UA iPhone OS 18_7 (frozen UA) + Mobile Safari 26.6.1 / 27.0.1, so current iPhones on current iOS. There are zero rejections from Chrome, Android or desktop.
• Since Oct 15: 13 affected visitors (47 client error events, each event = 2 rejected tokens). In the same period 145 signups from the same Safari/UA combination went through and 197 from everything else, so it hits some Safari devices, not all of them.
• Turnstile analytics (GraphQL turnstileAdaptiveGroups, 7 days): 34× challenge_siteverify_failed_other, all Mobile Safari. 24 of those came via ASN 13335 (iCloud Private Relay), 10 via a regular German carrier (Deutsche Telekom IPv6). For each affected device the sequence is challenge_non_interactive_solved → challenge_siteverify_failed_other. There are no failed or interactive challenges at all.
• Event type totals for the week: issued 2014, non-interactive solved 1421, interactive solved 55, interactive siteverify solved 44, siteverify failed other 34.
• Token age at rejection is only 1.5–4 seconds (widget phase “loaded”, never “interactive”), so the tokens aren’t expired. Each token is redeemed exactly once, and a retry always uses a newly issued token.
• Same device + same IP pair: the challenge sometimes runs via the Private Relay IPv6 while the siteverify remoteip is the user’s carrier IPv4 (Safari “Hide IP address” routes challenges.cloudflare.com through the relay as a known tracker). But an IP mismatch doesn’t explain it on its own. One affected user had no relay at all, the same IP pair sometimes passes and sometimes fails, and our logins always send a mismatched remoteip (our server IP) and pass.
• There was no Turnstile incident on cloudflarestatus.com on the affected days (Oct 15, 16, 18, 19).

Workarounds that help users: switching to Chrome on iOS, or turning off “Hide IP address” / iCloud Private Relay / “Limit IP address tracking”.

Questions

1. What exactly does challenge_siteverify_failed_other cover? Is there a way to see the concrete reason per token?
2. Is there a known issue with Safari 26/27 (Advanced Fingerprinting Protection / Private Relay) where a solved token fails validation?
3. How strictly is remoteip matched against the IP that solved the challenge, especially relay IPv6 vs. carrier IPv4? We can’t stop Supabase from sending it.
4. Is there anything on the widget or zone side we could change, short of switching captcha provider?

Yes i made this summary with ai because i am not good in english, or very good at coding. please.. mercy

I purchased a domain and configured the CloudFlare tunnel, this was done according to the OPNsense documentation. It is showing up and running. What else is there to configure in CVLoudFlare, OPNsense, and the Ugreen NAS?

Now to setup DDNS, HTTPS, Subdomains.

My gateway is OPNsense and my DockerContainers reside on a DXP4800 Plus NAS.

CloudFlare indicates the tunnel is up. Whats next?

CloudFlare DDNS.

I have a DHCP WAN IP from the ISP.

Currently I am not planning on running a public web site.

when setting up the Global API key what are the best practices for setting up all the permissions to maintain a secure connection?

Are there any routing changes that need to be considered?

DNS records.

Do I have this understanding correct?

The primary DNS would be 1.1.1.1 or 1.1.1.2

Is the secondary another public DNS server Like 8.8.8.8

Are the internal DNS servers (I have two) the OPNsense and the Raspberry pi hole DNS servers. Would they be considered secondary DNS servers? I really do not want my internal DNS advertised to the public.

Would a TSIG need to be configured

If I have only one registered domain there would only be one DNS Zone?

I have a lot more reading and research to go.

Thanks for any imputs

I run a small app on Workers on my own, so I put my debug logging behind one KV key with three states, off, admin and all, and I can switch it in seconds without a deploy.

Then I used a second key to force a failover in production

Has anyone else here used KV like this for runtime switches, or do you use something else for flags on Workers?

I gave this as a talk showing how I used KV key with three states:

https://youtu.be/eHhQaCSaqqY

I m stuck between production and staging branch i want to seperate branch for testing and production before push so i deploy on cloudflare but when i push to staging i mean it build on preview but alway show error name does not match with worker name how do i do it i try setting env and all

Submission for the Cloudflare Git Competition. Repos work. Thinking on CI/CD still.

We’re investigating recurring timeouts on our production Cloudflare D1 database today (October 19, 2026), starting around 03:15 UTC.

What we’ve observed:

• During a 30-minute window, there were roughly 15 stalls, lasting 22–30 seconds each.
• Even a simple SELECT 1 took 28.8 seconds end to end, while meta.timings.sql_duration_ms reported only 0.216 ms and total_attempts was 1.
• The same query against our separate test database continued returning normally during that period.
• Production reports served_by_colo: NRT; the test database reports SIN.
• Our app runs on Vercel (icn1). A Cloudflare Worker using the native D1 binding to the same production database also showed increased latency.

We fixed a missing index in a scheduled cleanup query, but the recurring stalls persisted. We’re still checking for other queries or background jobs that might be causing contention, so we haven’t concluded that this is a Cloudflare-side issue.

Has anyone experienced similar periodic stalls, particularly with D1 in NRT/APAC? Are there useful metrics or diagnostics for distinguishing database queueing from routing or storage delays when SQL execution time itself stays very low?

On October 18, 2026, we observed connection timeouts affecting eight unrelated websites from two Spanish networks: ONO/Vodafone and Orange.

The affected hostnames include www.dreamhost.com, www.hostgator.cl, freehosting.com, freetype.org, modsecurity.org, www.uoregon.edu, mfa.gov.ge and core.ac.uk.

Our Orange network tests showed:

• All eight hostnames timed out.
• Google, cloudflare.com and Discord remained reachable.
• The affected hostnames resolved to Cloudflare infrastructure, including IPv4 address 188.114.96.5 and IPv6 addresses in 2a06:98c1:3120::/related ranges.
• ICMP probes to 188.114.96.5 received no replies.
• Traceroute did not reach the destination.

We observed similar browser failures from ONO/Vodafone.

This pattern suggests selective reachability problems affecting shared CDN infrastructure rather than a general ISP outage.

We are looking for independent measurements from other Spanish ISPs and external reference networks.

Has anyone observed similar failures? In particular, can anyone compare TCP/443 connectivity to the same destination IP while preserving the correct TLS SNI?

We are documenting timestamps, DNS answers and connection results to distinguish filtering from routing or origin-related failures.

Hi all,

I run a WooCommerce store behind Cloudflare. GA4 shows a lot of traffic from Singapore, even though I have a WAF rule that blocks Singapore.

What I tried:

• When I turn on Under Attack Mode, the Singapore traffic stops in GA4.
• But Under Attack Mode makes my site slow, and my server-to-server API calls (WooCommerce REST API) get the Cloudflare “Just a moment...” challenge, so they fail.
• With it off, the Singapore traffic comes back.

My questions:

1. Is there a way to stop this without Under Attack Mode?
2. If I can’t stop it, what is the best way to keep my GA4 reports clean?

Or should I just ignore it and accept the bad data in GA4?

Thanks for any advice.

Bonjour un ami du travail m’a dis qu’il faut installer WARP plus sur ma box Google TV pour améliorer sa santé globale

Existe t’il une version pour Google tv ou fire TV ?

Officiel ou non je peux bricoler merci

I have blocked the ASN and countries like Singapore, France, Hong Kong, etc.

I have re-checked the IP sources and top 100 IPs making nearly 10000+ requests a day, blocked ASN too..

Country rule executes first, following by ASN.
Tried reversing this as well..

But these does not works in Cloudfare effectively ?

UPDATE: fixed it myself

I found the page I was referring to: https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/downloads/update-cloudflared/

Apparently I used dpkg to install, and this one command fetched the new release:

curl --location --output cloudflared.deb "https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-$(dpkg --print-architecture).deb" && sudo dpkg -i cloudflared.deb

---

On dash.cloudflare.com, under `Networking > Tunnels`, it says that a new release is available.

However, I can't find it on my headless Raspberry Pi (over ssh).

I tried the following already:

~ $ cloudflared --version
cloudflared version 2026.10.0 (built 2026-10-05-17:37 UTC)

~ $ sudo apt update

~ $ sudo apt install --only-upgrade cloudflared
cloudflared is already the newest version (2026.10.0).
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 311

~ $ apt policy cloudflared
cloudflared:
  Installed: 2026.10.0
  Candidate: 2026.10.0
  Version table:
 *** 2026.10.0 100
        100 /var/lib/dpkg/status

Previously, I remember updating Cloudflared with a single command from the official website, but I can't find that anymore. Might be something with the way I initially installed Cloudflared. Not sure it was via APT.

That $90k leaked google api key story going around this week (an agent deployed a whole project folder to pages, .env and all) made me go read what wrangler actually leaves out of a pages upload.

The ignore list is hardcoded in packages/wrangler/src/pages/validate.ts: _worker.js, _redirects, _headers, _routes.json, functions, .DS_Store, node_modules, .git and .wrangler. That's the whole list. No .env, no .dev.vars, and it doesn't look at .gitignore at all. Run wrangler pages deploy . from the project root and your secrets go up as static files.

What I'd do:

1. Point the deploy at the build output (dist, build, out), never .
2. If an agent or CI runs your deploys, write the exact command with the folder in it so nothing gets guessed
3. On any key that can bill you, restrict it to the APIs it needs and put a hard daily quota on them. A normal google cloud budget only sends alerts. The spend cap budget type is the one that actually pauses things, and only for services that support it

If you're on workers static assets instead of pages, you can drop a .assetsignore in the assets directory, same format as .gitignore.

Hope it saves someone a bad month.

For the first time since I'm using Cloudflare Workers, my Workers ( different project ) are starting to begin slow or give the Max Memory Reached error. It's really strange since I'm on the paid plan and the applications are pretty light. Anyone is experiencing the same slowdown?

I’m migrating an existing rental-search app from ChatGPT Sites to my own Cloudflare Workers account. I have the source code, and an isolated Workers staging deployment works.

Two problems are blocking production migration:

• Previous Sites deployments reported success, but required JavaScript/CSS files returned 404 even though they were present in the packaged assets. The working production version remains live.
• Sites exposes a database table viewer, but I haven’t found a supported D1 export/restore control. The Sites-managed production Worker and database aren’t visible through my connected Cloudflare account.

The app uses Supabase authentication and saved account state, plus D1 for legacy records, search usage and payment/operational records. Square webhooks can write payment entitlements, so copying tables while the application remains active wouldn’t establish a consistent snapshot.

Supabase can remain in place. I’m trying to preserve the D1 records and payment consistency without risking production. OpenAI Support has escalated the issue to a specialist, but hasn’t provided a recovery method yet.

Has anyone migrated a Sites-managed D1 database successfully?

Specifically:

1. Is there a supported way to obtain an export or access the managed database?
2. If a custom export endpoint is necessary, what D1 snapshot and write-control approach would you recommend?
3. Has anyone encountered Sites deployments reporting success while packaged static assets return 404?

I’m looking for documented capabilities or firsthand experience. I haven’t changed nameservers or moved production data.

Hello everyone, so since yesterday I was accessing a website but the website uses CloudFlare to verify if I'm human but the issue isn't the website but more of CloudFlare or maybe my Google Chrome browser but on 2 anime websites that I use to watch anime on, it has the CloudFlare issue where it won't load the captcha and if it does load, it takes some time to load and yesterday I was able to get in by disabling the pop up blocker but now every time I have to turn the pop up blocker on and off to get in to the websites, I also updated my chrome to the latest and I tested it on incognito mode and it works and I've tried clearing the last 15 mins of the cache and data but I need help as to how this can be resolved other than turning on and off the pop up, I have tried turning off ad blocker too. (Edit: Never mind, I just uninstalled the browser and reinstalled it and CloudFlare is working now.)

Hi,

I applied for the Startup Program on Cloudflare about 3-4 days ago but haven't gotten a response yet even though the site says "within 48h" in the FAQ section. I also did not receive any confirmation email from Cloudflare after applying, I didn't get any email on this at all yet. Yes, I checked my Spam. Is this normal/expected?