今日已更新 84 条资讯 | 累计 37333 条内容
关于我们

标签:#cloudflare

找到 49 篇相关文章

开发者

Cloudflare KV for Session Caching in Multi-Tenant FastAPI: Reducing PostgreSQL Load Without Redis Complexity

Cloudflare KV for Session Caching in Multi-Tenant FastAPI: Reducing PostgreSQL Load Without Redis Complexity Every SaaS I've built hits the same wall: session validation on every request hammers PostgreSQL. You add Redis, suddenly you're managing another service, debugging cache invalidation, and paying for redundancy you don't need. Then I discovered Cloudflare KV sits between your users and origin server. It's not a replacement for PostgreSQL—it's a read cache positioned at the edge that auto-syncs on writes. For multi-tenant session and permission data, this eliminates 60–80% of auth-related database queries without the operational complexity of Redis. This is the approach I use in CitizenApp. Here's why it works, how to implement it, and where I nearly broke production. Why Cloudflare KV Beats Redis for Session Caching Redis requires: A separate service deployment (Render, AWS ElastiCache) Connection pooling logic in your app Cache invalidation strategies you'll get wrong Monitoring for memory leaks and eviction Cost that scales with your hot data size Cloudflare KV requires: A binding in your edge worker (one line of config) Simple key-value storage at 200+ edge locations Automatic TTL expiration Zero operational overhead—Cloudflare manages it Here's my honest take: I prefer KV because I don't have to think about it. My workers validate JWT tokens and fetch session data from KV before even routing to my FastAPI origin. Cache misses flow to PostgreSQL and write back to KV. No connection pools. No eviction policies. No debugging Redis memory fragmentation at 3 AM. The tradeoff? KV is slower than in-memory Redis (ms vs microseconds), but for session lookups happening 200+ times per second per user at global scale, edge-cached responses beat origin-fetched ones every time. Architecture: Edge Validation + Origin Sync Your flow looks like this: Request hits Cloudflare Worker Worker checks KV for session + permissions (hit = serve immediately) KV miss → fetch from Fas

2026-08-29 原文 →
AI 资讯

Even Cloudflare Is Now Issuing Wallets to AI - The 'Spending Cap' Everyone's Racing to Build Is What Actually Makes AI Safe to Spend Money

Honestly, when I saw Cloudflare's announcement, my first reaction wasn't "oh cool, something new"—it was "there goes another giant company proving the thing I've been saying all along." What Cloudflare Actually Did On August 4, Cloudflare (yes, the infrastructure giant that blocks traffic and runs CDNs for half the internet) launched "Cloudflare Wallets" and something called cloudflare.pay. It gives AI agents three things they didn't have before: An identity —a recognizable wallet handle so others know exactly which agent is paying A wallet —funded with stablecoins, so the agent can actually pay A spending cap —and this one is enforced by Cloudflare's infrastructure itself The structure here is what I think matters most. You (the human) hold an Account Wallet where the funds live; then, through an API key, you grant a limited slice of spending power to individual Virtual Wallets that your agents actually use. Here's the analogy that makes it click: the Account Wallet is your company's master account, and each Virtual Wallet is a prepaid card with a spending limit that you hand to one of your AI employees. The only difference is these "employees" are AI, and the limit on the card isn't managed by a credit card company's risk engine—it's written directly into Cloudflare's infrastructure. Payments run through the now widely-discussed x402 protocol: an agent wants to buy a service, and it pays for that one transaction on the spot with stablecoins. I should be upfront about something: it's not fully usable yet. As of August 5, it's in a "launched, you can reserve your cloudflare.pay name" state. The real funding, Virtual Wallets, and programmatic spend controls are, per Cloudflare, coming "over the next few months." So this is a clear directional statement, not a mature product you can fully adopt today. Why I'm Not Reading This as "One New Product"—I'm Reading It as an Industry Consensus If this were just Cloudflare doing its own thing, I wouldn't bother writing about i

2026-08-26 原文 →
AI 资讯

Cloudflare OS: Cloudflare's Open-Source Corporate AI Platform Built on a Capability-Based Model

Cloudflare recently open-sourced Cloudflare OS. It allows enterprise teams to output work artifacts grounded in enterprise knowledge, know-how, and provisioned connectors, automate repetitive workflows with optimized token cost (with AI assistance only where needed), and build personal, shareable, customizable work software that caters to specific, complex use cases within a secure sandboxed model By Bruno Couriol

2026-08-24 原文 →
开发者

Cloudflare Announces Kitesurf, a Browser Engine for Agents

Cloudflare recently introduced Kitesurf, a lightweight browser built for automated workloads. Kitesurf runs browser components in isolated WebAssembly/Rust environments on Cloudflare Workers and supports the Chrome DevTools Protocol, allowing tools such as Playwright and Puppeteer to drive it with lower resource overhead than a full Chromium browser. By Renato Losio

2026-08-22 原文 →
AI 资讯

Cloudflare Cuts Astro Github Issues by 85% with AI Agents

Cloudflare, Astro, AI agents, GitHub Actions, issue triage, agentic AI, software architecture, open source, developer tools, AI automation, automated testing, human in the loop, agent workflows, GitHub, software engineering, AI software development, bug triage, continuous integration, developer productivity, autonomous agents, AI coding, Cloudflare Workers, Flue, triagebot By Leela Kumili

2026-08-21 原文 →
AI 资讯

Cloudflare's AI block names eight crawlers. None is ChatGPT's search bot

Eight user agents, and the one that decides whether ChatGPT cites you is not among them. An r/SEO post from April, 53 points and 40 comments, says Cloudflare quietly cut the author's site off from ChatGPT, from Perplexity and from Google's AI Overviews. I went and read the block. It names ChatGPT's training crawler and not its search crawler, and it never mentions Perplexity at all. The Google agent it does name is one Google says does not affect inclusion or ranking in Search. Take just two of the eight agents. GPTBot governs inclusion in OpenAI's training data, and Google-Extended governs grounding in Gemini Apps. Those are real things to give up. They are not the three things the warning names. What is actually in the file Cloudflare prints the whole block on its managed robots.txt page : # BEGIN Cloudflare Managed content User - Agent : * Content - signal : search = yes , ai - train = no , use = reference Allow : / User - agent : Amazonbot Disallow : / User - agent : Applebot - Extended Disallow : / User - agent : Bytespider Disallow : / User - agent : CCBot Disallow : / User - agent : ClaudeBot Disallow : / User - agent : Google - Extended Disallow : / User - agent : GPTBot Disallow : / User - agent : meta - externalagent Disallow : / # END Cloudflare Managed Content Read that against Cloudflare's own crawler reference table and a pattern falls out. GPTBot is in, OAI-SearchBot is out. ClaudeBot is in, Claude-SearchBot is out. For both of those pairs the table calls the blocked agent an AI Crawler and the one left alone AI Search. Applebot-Extended is in and plain Applebot is not, the same split again. The table has no Applebot-Extended row, so it cannot tell you what Cloudflare calls that one. The block runs along the training and search seam, and that looks deliberate to me. OpenAI's side of it is one line: "Each setting is independent of the others". I worked through the three OpenAI bots and which one governs search visibility in an earlier post , so I will

2026-08-18 原文 →
AI 资讯

Cloudflare Turns CI Pipelines into TypeScript Workflows

Cloudflare has released cloudflare/ci, a CI SDK that defines pipelines in TypeScript on top of Cloudflare Workflows, giving each step durable retries and replay, concurrent steps by default and Sandbox snapshot caching. It targets the Workers runtime and depends on Artifacts, still in private beta, so the transferable lesson is the durable-step model rather than a drop-in CI replacement. By Mark Silvester

2026-08-17 原文 →
AI 资讯

My evidence pipeline was saving Cloudflare block pages as evidence

I build a web service that preserves evidence of harassment on social platforms. The core feature is a single thing: automatically capture a real screenshot of the offending post. There was no substitute for it. I built an alternative that pulled the text through an API and rendered a tidy "evidence card" image, and threw it away. An image you can author freely afterwards proves nothing. Here's the conclusion first. Third-party wrappers eventually die, and when they do, the failure comes back as a plausible-looking image rather than an error. The first approach was refused by the other side I started with Cloudflare Browser Rendering. The wiring worked. The capture didn't. X blocks headless browsers. The request times out YouTube refuses script injection under a Trusted Types CSP. There's no way to make it render the comment Neither is a bug in my implementation — that is how they are built. So I declared Cloudflare alone impossible for this and moved to a service with a real browser and bot avoidance behind it. Both captures started working. For X, open the post page and clip the tweet element. For YouTube, open the URL with &lc= and screenshot just that comment element. Element screenshots have one trap worth knowing: selector_algorithm=clip returns a blank image when the element sits below the fold. The selector matches, the capture "succeeds," and the file is empty. That took a while to see. ytd-comment-thread-renderer :has ( a [ href *= "lc=ID" ]) A parameter that had worked started returning 400 I wanted timestamps rendered in Japan time, so I passed time_zone: Asia/Tokyo . One day every request started coming back 400. Every capture failed. The provider had narrowed which timezones they accept. Nothing changed on my side. I could diagnose it immediately only because I was storing the raw error body in the database. The response went into rawPayload.screenshotError , so opening one row told me why. Without that, this starts as "captures stopped working, no ide

2026-08-15 原文 →
AI 资讯

CloudFlare Previews Automatic WebMCP Support for Web Pages

Cloudflare announced a developer preview that lets any website enable a WebMCP (Web Model Context Protocol) interface with a single dashboard switch. This allows browser-based AI agents to interact with unmodified web pages through structured tools instead of scraping or guessing, keeping human traffic and control on the original site. By Sergio De Simone

2026-08-11 原文 →
AI 资讯

Your MCP server's real constraint is the context window, not the API

We use AskElephant to record client calls, and we work in claude.ai. Those two things could not talk to each other, and the reason is structural rather than a missing feature. AskElephant ships an MCP server. It runs locally over stdio, which serves Claude Desktop, Cursor, VS Code and Windsurf. A browser cannot spawn a process on your laptop, so claude.ai needs an MCP server at an HTTPS address. That is a different program. Building it took about a day. Working out what it should refuse to do took considerably longer, and that part generalises to any MCP server sitting in front of a large corpus. The code is on GitHub . The arithmetic that determines the design Before writing tools, measure your payload. We measured every transcript in our account: 3,706 engagements, 2,230 of which carry one. Characters Approx tokens Average transcript-bearing call 32,485 8,100 Median 28,240 7,060 p95 75,543 18,885 Largest 175,643 43,900 The largest single call is more than a fifth of a 200,000-token context window on its own. Now consider the actual user request: "find where we discussed pricing with this client this year." That touches maybe forty calls. The naive tool returns forty transcripts, which is roughly 325,000 tokens. It does not fit. Not slow, not costly: impossible. So the design constraint is not the API. It is arithmetic, and it arrives before you write a single tool definition. Do the reading on the server The whole design collapses to one line: The Worker does the reading. Claude does the thinking. search_transcripts fetches the candidate transcripts, scans them inside the Worker, and returns only matching passages with speaker and timestamp attached. A real forty-meeting search, run through claude.ai against the live archive, returned 76,757 characters of excerpt: about 19,200 tokens rather than 325,000. The scanner is a pure function with no IO, which makes it trivial to test: export function scanTranscript ( text : string , queries : string [], opts : ScanOption

2026-08-04 原文 →