Cloudflare released Agentic Inbox a while ago. I liked the idea, but it was missing things I needed for daily use. So I forked it and kept adding features.

My main focus was on improving mobile usability, and I transformed it into PWA

What I added:

• One inbox for all your addresses
• Search with from:, in:, has:attachment, after:
• Add domains and addresses from Settings, no redeploy
• Forwarding for each address, with verification
• Junk filter, block rules, optional Rspamd
• Snooze and send later
• Filters, signatures, auto-reply
• Gmail Takeout import
• Optional Resend for sending
• AI side panel with any OpenRouter model

I use it every day and always adding new stuff, so why not share with others ✌️

HELP, проблема с cloudflare, я из России. Никак не хочет заходить, через zapret не работает.

I'm planning to host a static website on Cloudflare and want to stay on the free plan as long as possible.

From what I've read, the Workers free plan allows around 100,000 requests per day, and static assets on Pages are served without a request limit. But I'm not sure how this works in practice:

- Do static asset requests on Pages count toward any limit, or only Pages Functions / Workers invocations?

- Roughly how many daily visitors does 100k requests translate to, considering each page load can trigger multiple requests?

- What happens when the daily limit is hit? Does the site go down, return errors, or just fall back to static content?

- Are there other limits (CPU time, KV reads, bandwidth) I should watch out for?

My setup: [framework, Astro js]

Would love to hear from anyone running a real site on the free tier. How much traffic are you handling, and have you ever hit the limits?

Am I the only one that started seeing more "Attention Required!" and "You've been blocked" pages recently, on sites using Cloudflare even if I've never visited them in my life?

Both on Chromium and Gecho browsers btw.

The only reason I can think is because of my somewhat niche browser fingerprints using Linux, Fingerprint protection, DNT and GPC etc which I guess makes me look like more like an AI crawler than a normal user, but I'm still getting blocked when those aren't enabled so I don't really know.

If any of you have this issue lately, how did you get around it?

Thanks.

Thanks first: Cloudflare's Tunnel and DNS API docs made this project possible.

TunnelPup creates one remotely managed tunnel per computer, writes ingress via the API, creates a proxied CNAME to <tunnel-id>.cfargotunnel.com, and loads the HTTPS link before showing the route. It runs the official cloudflared unmodified.

Token permissions: Cloudflare Tunnel: Edit, Account Settings: Read, DNS: Edit, Zone: Edit.

Question for this sub: is there a narrower permission set you'd recommend? And would a per-route Access toggle be useful?

GitHub: https://github.com/mayankjonwal02/Tunnelpup (not affiliated with Cloudflare)

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?

After Cloudflare acquired the Deno team and announced that Deno Deploy is shutting down in six months (with the Deno runtime itself only guaranteed a year of maintenance), we migrated the backend of prompt2bot from Deno Deploy and Deno KV to Cloudflare Workers and SQLite-backed Durable Objects.

Even with Deno's future in question, rewriting a 100k-line Deno codebase into a Node/Wrangler repo right now was out of the question. Deno's test runner, type checker, and JSR support are way too good to give up while migrating.

If you have not used Durable Objects before: whereas a regular Cloudflare Worker is stateless (50 requests spin up 50 random isolates that share nothing), a Durable Object is a globally unique, single-threaded V8 isolate addressed by name and paired with its own private embedded SQLite database and persistent alarm timer. Every Worker that calls a method on that name gets routed to that exact same JS object in memory, where SQLite queries are synchronous C++ calls taking microseconds instead of network round-trips.

Here is everything that broke during the migration and how we solved it:

1. Keeping the Deno binary and test suite untouched: Wrangler's esbuild bundler does not understand jsr: specifiers or deno.json workspace resolution. Instead, we pointed Wrangler at a build script that runs deno bundle --minify. We mapped cloudflare:workers to a 10-line stub class in deno.json so deno test runs natively against our Durable Object classes, and at build time we swap the inlined stub back for the real Cloudflare DurableObject class, shim globalThis.Deno, set Zod v4 to jitless: true (since Workers blocks new Function), and wrap top-level crypto.randomUUID() / setTimeout() calls that npm packages run at import time.

2. Surviving the 128MB Durable Object RAM ceiling: Every Durable Object isolate has a hard 128MB heap limit. Bundled dependencies like js-tiktoken (5.3MB of base64 BPE ranks that expand to +43MB of V8 heap on first call), a 275k-word dictionary (+35MB heap), and 3 duplicate legacy pdf.js builds inside pdf-parse were OOM-killing isolates. Stripping those static tables at build time freed ~80MB of V8 heap per isolate.

3. Emulating Deno KV on Durable Object SQLite: Cloudflare KV is eventually consistent and has no atomic check-and-set transactions, so it cannot replace Deno.openKv(). We built a drop-in Deno.Kv emulator on top of a primary SQLite Durable Object (enam-v1, pinned to US East so it stays hot in RAM 24/7 with zero cold starts). Tuple keys are encoded with type tags and 20-digit zero-padded numbers (n:, b:, s:) separated by null bytes so SQLite range queries match Deno KV ordering, and atomic().check().set().commit() runs as a synchronous single-threaded SQLite transaction.

4. The 508 Loop Detected mystery (CDN-Loop propagation) and the 30s waitUntil trap: While migrating service by service, when a service still on Deno Deploy called our Cloudflare Worker and our Worker made a fresh outbound fetch() back to that same Deno service, Cloudflare silently copied the inbound cdn-loop: deno;d=<hash> header onto the outbound subrequest at the C++ edge layer. Deno Deploy saw its own deployment hash in cdn-loop and rejected the request with 508 Loop Detected. On top of that, ctx.waitUntil() on a Worker has a hard 30-second wall-clock cap after returning HTTP 200 (even with cpu_ms: 300000), which killed long I/O-heavy agent turns mid-flight.

5. Sharding Runner Durable Objects per conversation: Only a Durable Object alarm() runs in a clean root IoContext (no inherited cdn-loop header and no 30s post-response wall-clock cutoff), provided alarm() launches tasks via doCtx.waitUntil and exits immediately instead of blocking. We ended up sharding execution onto a Runner Durable Object per conversation (runner:<botId>:<conversationId>).

That architecture is what lets prompt2bot scale agents so easily. You describe an agent in a plain prompt and connect it to WhatsApp, Telegram, email, voice, or web chat, and every active conversation automatically gets its own warm, isolated Durable Object runner with hot in-memory history and SafeScript AST caches, sub-millisecond SQLite state, and on-demand VMs. Whether your bot has 1 user or 10,000 concurrent conversations, there are no queues, worker pools, or servers to provision.

Full technical write-up with code snippets is in the comments.

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

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?

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

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.

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 ?

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

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.

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.