cloudflareAug 7, 2026

Announcing Cloudflare Ambassadors, Community Engineers, and another $1M in open-source funding (opens in new tab)

Cloudflare is launching an expanded community program to support people who help others build on and improve the Internet. The program has two tracks: Cloudflare Ambassadors, who grow local and online developer communities, and Cloudflare Community Engineers, who contribute to open-source projects. It also includes new funding, recognition, and improvements to Cloudflare’s growing Discord community. ## Cloudflare Ambassadors - Ambassadors bring Cloudflare into their own communities through: - Local events, meetups, hackathons, and workshops - Student groups and campus activities - Tutorials, online content, and peer support - Selected Ambassadors receive: - Event credits and marketing support - Technical resources - Greater visibility in Cloudflare’s online communities, including Discord - Ambassadors can serve for up to two years. - Applications are open through September 6, with selections announced by October 5. - Cloudflare highlights the program’s goal of helping developers—especially students overcome resource limitations and turn ideas into working products. ## Cloudflare Community Engineers - This track supports developers who maintain or contribute to open-source software that benefits the broader Internet. - Cloudflare is adding $1 million in funding over two years for grants to eligible contributors. - The initiative builds on previous investments, including: - Sponsorship of TanStack - A $1 million fund supporting the Vite community through VoidZero - Community Engineer appointments have no fixed maximum term, recognizing that open-source maintenance and major contributions do not fit neatly into annual cycles. - Initial focus areas include projects related to Cloudflare’s ecosystem, such as Astro, Agents SDK, EmDash, Hono, and Vinext. - Grants will become available through a later application process. ## Improving the Cloudflare Discord Community - Cloudflare’s Discord has grown to nearly 100,000 members since its launch in 2020. - A new Discord committee, including Ambassadors and Cloudflare staff, will focus on: - Improving discussions and community content - Connecting developers with Cloudflare experts - Organizing conversations and sessions with internal teams - Automated tools are being introduced to reduce spam, malicious links, and routine moderation work. - Cloudflare plans to open-source these Discord protection tools so other communities can use them. - The committee is intended to focus on meaningful community opportunities rather than administrative tasks. Cloudflare’s overall recommendation is to get involved through the new community program at **cloudflare.com/community**, whether by organizing developer communities or contributing to open-source projects.

astrodiscordcloudflareopen-source+4

cloudflareAug 4, 2026

How we built a software factory to drive Astro’s GitHub issue count to zero (opens in new tab)

AI-powered software factories can address a pressing open-source problem: maintainers are overwhelmed by the flood of AI-generated issues, pull requests, and security reports. The Astro team built an automated triage pipeline that reproduces bugs, diagnoses causes, creates fixes, and ships preview releases for verification. After several months, it reduced Astro’s open issues from more than 200 to roughly 30 without mass-closing or ignoring reports. ## Building an Issue-Triage Skill - The team began by automating issue triage, one of the most time-consuming parts of open-source maintenance. - The workflow mirrors manual debugging: - **Reproduce:** Clone the reporter’s reproduction repository and confirm the problem. - **Diagnose:** Instrument the code and add logging to identify the root cause. - **Verify:** Check tests, documentation, and comments to determine whether the behavior is actually a bug. - **Fix:** Turn the reproduction into failing tests, implement a solution, and deploy it. - Each phase runs in an isolated AI subagent to reduce the tendency to force a solution. - Subagents communicate through a sequential `report.md` file containing their findings. ## Running the Pipeline in GitHub Actions - The workflow is driven by GitHub issue labels rather than a separate internal database. - New issues begin with `triage needed`; verified fixes eventually move to `fix verified`. - The pipeline reconstructs its state from labels and existing issue comments. - When a fix is ready, it: - Creates a preview release using `pkg.pr.new`. - Posts the diagnosis, logs, and installation instructions to the issue. - Lets the original reporter test the patch. - Opens a linked pull request after confirmation. ## From a Repository Workflow to Flue - The team recognized that the process was not inherently tied to GitHub. - Its core structure consists of: - An external event. - A sequence of isolated subagents. - Separate reasoning and execution permissions. - Durable workflow state. - This generalization became **Flue**, an open, platform-agnostic framework for agent workflows that can respond to GitHub events, Slack messages, cron jobs, or webhooks. ## Effects on Maintainer and Community Work - Automation did not make the Astro team less connected to users. - Instead, it freed maintainers to spend more time: - Engaging with the community in Discord. - Participating in RFCs and feature discussions. - Collaborating with contributors. - The system is designed to resolve most incoming issues, while failures are treated as signals that the codebase needs improvement. ## Using Agent Failures to Improve the Codebase Agent mistakes often reveal problems that would also challenge human developers: - **Opaque abstractions:** Component boundaries are unclear. - **Missing documentation:** Important implementation decisions are unexplained. - **Insufficient testing:** Critical behavior lacks adequate unit tests. - For example, the bot repeatedly changed an HMR-related condition and caused regressions because the logic was poorly documented and under-tested. - Adding a precise comment clarified the intended behavior, after which the bot stopped making the same incorrect change. - Fixing these weaknesses improves both future automation and human maintainability. ## Extracting the Workflow into a GitHub Action - Initially, the triage system was embedded in the Astro monorepo, making changes risky and difficult to test. - The team separated it into the standalone `triagebot-action` repository. - This enabled independent testing and safer updates to Flue and the workflow. - The action now supports Astro and has been adopted or forked by other teams building their own automated development pipelines. The practical lesson is to start with a narrow, repeatable maintenance task, isolate agent responsibilities, make all reasoning auditable, and use failures to improve documentation, architecture, and tests.

astroai-agentopen-sourcegithub-actions+4

cloudflareAug 4, 2026

How Cloudflare enforces engineering standards using AI (opens in new tab)

Cloudflare built the Codex to turn scattered engineering knowledge into governed, machine-readable standards that both engineers and AI agents can apply consistently. It now supports code reviews, technical design reviews, and incident reviews, with AI systems flagging nearly 230,000 violations and blocking about 16,000 merges. The central approach is to combine human-owned RFCs with structured extraction, staged enforcement, and context-aware agents. ## Why Cloudflare Built the Codex - Engineering guidance previously existed across formal documentation, repositories, chat, and individual experience. - Engineers struggled to determine whether guidance was current, authoritative, or relevant. - Growth made it difficult for anyone to know every standard or for reviewers to check every requirement. - The Codex provides a shared source of truth that can be retrieved and applied at the point of work. ## Governance and RFC Workflow - The Codex is divided into domains such as: - Architecture and control plane systems - Security and reliability - Programming languages including TypeScript and Rust - Each domain has an owner responsible for content quality and consistency. - Standards follow an RFC format using RFC 2119 terminology: - **SHOULD** for recommendations - **MUST** for mandatory requirements - Employees can propose RFCs through structured merge requests. - Proposals undergo increasingly broad review before domain-owner approval. - Approved RFCs are published to an internal Astro-powered site. - Enforcement is deliberately separated from approval: - Approved standards can generate findings. - Only enforced standards can block merges. - This gives teams time to adopt requirements and implement enforcement mechanisms. ## Structured Standards for Agents - Feeding all 60-plus RFCs directly into an LLM would consume too much context and reduce accuracy. - A dedicated agent extracts SHOULD and MUST statements into structured JSON. - Each statement includes: - A stable slug - RFC and domain metadata - Requirement level - Section and source link - Stable identifiers allow Cloudflare to track requirements across RFC revisions, systems, monitoring, and exception handling. - Cloudflare moved from concise Markdown extraction to JSON to enable filtering and progressive disclosure. - Future metadata may identify which SDLC stage applies, such as design, implementation, or runtime. ## AI Code Review - The AI code reviewer retrieves relevant statements first and loads complete RFCs only when more context is needed. - Approved-RFC findings are non-blocking recommendations. - Violations of MUST requirements in enforced RFCs can withhold approval or block a merge. - Since launch, the reviewer has: - Flagged nearly 230,000 violations - Withheld approval for almost 16,000 violations ## Faster Code Review Alternatives - Full AI reviews generally take several minutes because they use coordinators and multiple agents. - To reduce remediation delays, Cloudflare is also developing mechanically verifiable checks. - Language-specific Codex requirements can be distributed through custom linter configuration packages. - TypeScript was the first language to receive Codex linter support, alongside standardization on oxlint. The Codex’s practical value comes from connecting governed human standards to automated enforcement. Cloudflare’s staged RFC lifecycle, stable statement identifiers, and combination of AI review with fast linters provide a scalable way to preserve engineering knowledge while reducing review inconsistency.

astrollmtypescriptrust+4

githubJul 8, 2026

Automating cross-repo documentation with GitHub Agentic Workflows (opens in new tab)

The Aspire team used GitHub Agentic Workflows to automate documentation across its product and documentation repositories. For versions 13.3 and 13.4, the system produced 82 documentation pull requests, typically within 44.8 hours of the corresponding product change, with review from the engineer who shipped the feature. The approach combines AI-generated drafts with deterministic branch selection and tightly controlled write permissions. ## The Cross-Repository Documentation Problem - Product code lives in `microsoft/aspire`, while documentation lives in `microsoft/aspire.dev`. - The old process depended on writers discovering changes weeks later and reconstructing intent from closed pull requests. - Engineers often had limited context by the time clarification was requested. - Broad repository tokens were unacceptable, making secure cross-repository automation difficult. ## How GitHub Agentic Workflows Work - Workflows are authored as Markdown files with YAML-style frontmatter and natural-language instructions. - A compiler generates a standard GitHub Actions `.lock.yml` workflow. - An agent analyzes repository data and produces proposed actions as JSON rather than writing directly to GitHub. - A separate “safe-outputs” handler executes only explicitly permitted actions through a narrowly scoped GitHub App. - This separation provides AI flexibility while preserving security controls and auditability. ## The Automated Documentation Pipeline - The `pr-docs-check.md` workflow runs when a pull request is merged into `main` or a `release/*` branch. - A deterministic Bash script resolves the documentation target branch before the agent runs: - Product pull request milestone, such as `13.4`, maps to `release/13.4`. - Linked issue milestones are checked next. - The pull request’s base branch is used if it matches a release pattern. - Otherwise, documentation targets `main`. - The agent: - Reviews the product diff and linked issues. - Determines whether documentation is necessary. - Checks out `microsoft/aspire.dev`. - Writes documentation using the project’s existing writing conventions and Starlight/MDX components. - The workflow creates a draft documentation pull request with: - A `[docs]` title prefix. - The `docs-from-code` label. - A restricted base branch. - The documentation repository as the target. - The subject-matter expert who reviewed the original product pull request as reviewer. - A comment containing the documentation pull request link is posted back to the source pull request, while older workflow comments are minimized on reruns. ## Security Through Safe Outputs - The agent receives constrained GitHub tools and read access. - Repository access is limited through allowed repositories and a dedicated GitHub App. - Actions must use pinned, integrity-checked components through `min-integrity: approved`. - Write operations are restricted to declared safe outputs, such as creating pull requests. - Documentation changes remain drafts and are never auto-merged. ## Results and Broader Fit - The process eliminated the need for additional staff or major process training. - Documentation drafts arrive shortly after the related code is merged, while the implementation context is still fresh. - The workflow preserves human review by routing drafts to the engineer or SME who approved the feature. - Both the automation documentation and `aspire.dev` use Astro and Starlight, making the tooling and publishing environment closely aligned. The practical recommendation is to use agentic automation for drafting and routing documentation, but keep branch resolution, permissions, and final review deterministic and human-controlled. This provides much of the speed of autonomous workflows without granting an AI agent unrestricted repository write access.

astroai-agentgithub-actionsgithub-agentic-workflows+3

cloudflareApr 1, 2026

Introducing EmDash — the spiritual successor to WordPress that solves plugin security (opens in new tab)

EmDash is presented as a modern, TypeScript-based successor to WordPress, designed for today’s serverless hosting environment. Its central innovation is isolating plugins in sandboxed Dynamic Workers and granting them only explicitly declared capabilities. The project aims to preserve WordPress’s open-source publishing model while addressing plugin security, marketplace dependence, and licensing concerns. ## Modernizing WordPress for Today’s Web - WordPress powers more than 40% of the Internet but was designed when hosting commonly meant managing virtual private servers. - EmDash is: - Written entirely in TypeScript - Built on Astro - Serverless, while still deployable on personal hardware or Node.js servers - Fully open source and MIT licensed - Intended to remain compatible with WordPress-style functionality without using WordPress code - Version 0.1.0 is available as an early developer beta for Cloudflare or Node.js deployment, along with an online playground. ## Building on WordPress’s Publishing Legacy - WordPress democratized publishing and created a large ecosystem of core contributors, plugin developers, and theme developers. - The authors argue that WordPress will continue to have a role, but newer developers increasingly use Astro and TypeScript frameworks. - EmDash seeks to provide a similarly accessible, inexpensive, and open publishing platform suited to modern development practices. ## Sandboxed Plugins and Explicit Permissions - WordPress plugins are PHP scripts with direct access to the site’s database and filesystem. - This lack of isolation is identified as the source of most WordPress security problems: - 96% of WordPress site security issues reportedly originate in plugins. - High-severity vulnerabilities increased substantially in 2025. - EmDash runs each plugin inside an isolated Dynamic Worker. - Plugins access platform functionality through capability-based bindings rather than direct access to underlying resources. - A plugin must declare its required permissions in its manifest, allowing administrators to evaluate permissions before installation. - The example notification plugin: - Reacts to content-save events - Checks whether a post has been published - Sends an email to editors - Logs the notification - Plugins have no general external network access. If network access is necessary, the plugin can request permission for specific hostnames. - Administrators or platforms could enforce installation policies based on requested permissions instead of relying solely on approved-plugin allowlists. ## Security, Marketplaces, and Licensing - WordPress.org manually reviews plugins because the platform cannot otherwise guarantee their safety. - The review queue reportedly exceeds 800 plugins and can take at least two weeks. - Marketplace reputation, ratings, and reviews therefore become essential substitutes for technical trust. - Because WordPress plugins run inside WordPress and are tightly coupled to its code, developers may also face GPL licensing constraints. - The article argues that plugin security creates marketplace lock-in: - Customers rely on marketplaces to assess plugin trustworthiness. - Developers may need to distribute code under restrictive licensing terms to participate. - Hosting platforms inherit the risk of running third-party plugins. - EmDash’s sandboxing and permission model is positioned as a way to reduce reliance on centralized marketplace approval, though the provided article excerpt ends before explaining the promised “two important properties” in full. EmDash’s practical recommendation is to use capability-limited, isolated plugins as the foundation for a more secure and flexible WordPress-like ecosystem. Its early beta is intended for developers who want to evaluate that model on Cloudflare or Node.js.

astrodatabase-designopen-sourcetypescript+4

cloudflareJan 30, 2026

Building vertical microfrontends on Cloudflare’s platform (opens in new tab)

Cloudflare’s new Vertical Microfrontends (VMFE) Worker template lets independent teams map separate Workers to different URL paths on one domain. Unlike horizontal microfrontends, each team owns an entire vertical slice—including its framework, frontend, deployment pipeline, and operations. The approach enables technology flexibility and team autonomy while using view transitions and preloading to preserve a seamless user experience. ## Vertical Microfrontend Architecture - Applications are divided by URL path rather than by components on a single page: - `/` → Marketing - `/docs` → Documentation - `/blog` → Blog - `/dash` → Dashboard - Routes can be split into more granular verticals, such as: - `/dash/product-a` → Worker A - `/dash/product-b` → Worker B - Each route can be an entirely separate frontend project with its own: - Framework and libraries - Codebase - CI/CD pipeline - Owning team - This allows teams to choose technologies suited to their needs—for example, Astro for marketing and React for a dashboard. - It also reduces the risk of monolithic releases, where one team’s regression can force multiple teams to roll back. - Cloudflare applies a similar model internally, routing users from its core dashboard to separate products such as Zero Trust based on URL paths. ## Creating a Unified Experience - Independent applications must still appear cohesive to users. - Users generally accept distinct experiences between marketing, documentation, and dashboards. - However, related areas within one product—such as `/dash/product-a` and `/dash/product-b`—should not expose their separate repositories or Workers. - The goal is to hide implementation boundaries while preserving independent ownership. ## CSS View Transitions - Navigating between separately deployed Workers can otherwise produce a brief blank screen while the next document loads. - CSS View Transitions can preserve shared elements, such as navigation, during page changes. - The transition API allows teams to: - Keep DOM elements visible across navigations - Animate differences between the old and new pages - Make multi-page applications feel more like a single-page application - A small CSS rule can assign a transition name to the navigation and apply an eased animation to the page transition. ## Document Preloading - Seamless animation is not enough; navigation should also feel immediate. - The Speculation Rules API lets compatible browsers prefetch likely future document navigations. - Teams can define a `script` with `type="speculationrules"` and list URLs for related vertical slices, such as links in shared navigation. - Chrome, Edge, and Opera support the newer API, while Firefox and Safari currently do not. Cloudflare’s VMFE approach is most useful when teams need independent ownership and technology choices without sacrificing a unified product experience. Path-based Worker routing, shared visual conventions, view transitions, and selective prefetching provide the foundation for making separate applications behave like one.

astroreactcloudflare-workersmicrofrontends+3

cloudflareJan 16, 2026

Astro is joining Cloudflare (opens in new tab)

Astro Technology Company is joining Cloudflare, with the Astro team continuing to develop the framework as Cloudflare employees. Astro will remain MIT-licensed, open source, portable across platforms, and governed through a public roadmap and open contributions. The partnership aims to strengthen Astro’s role as a fast, accessible framework for content-driven websites, with Astro 6 introducing major development and runtime improvements. ## What the Cloudflare Acquisition Means - Astro remains: - Open source and MIT-licensed - Open to community contributions - Supported by a public roadmap and open governance - Deployable across any cloud or hosting platform - Astro’s full-time employees are joining Cloudflare and will continue working on the framework. - Cloudflare will support the Astro Ecosystem Fund alongside partners such as Webflow, Netlify, Wix, Sentry, and Stainless. - The project’s commitment to portability and platform independence will not change. ## Why Developers Choose Astro Astro has focused on content-driven websites rather than attempting to serve every type of application equally. - **Content-driven:** Built to showcase websites’ content. - **Server-first:** Renders HTML on the server for better performance. - **Fast by default:** Designed to make slow websites difficult to build. - **Easy to use:** Accessible without deep JavaScript tooling expertise. - **Developer-focused:** Provides tools and resources intended to support successful development. Astro’s Islands Architecture supports this approach: - Most pages are delivered as fast, static HTML. - Interactive sections can be rendered as client-side “islands.” - Developers can use multiple UI frameworks on the same page, including React, Vue, Svelte, and Solid. ## Shared Vision for Web Development Cloudflare and Astro share a goal of making the web faster and easier to build on. - Astro was created in 2021 to simplify the increasingly difficult process of building fast websites. - Its simple, structured foundation also helps coding agents and AI-assisted development produce better results. - Platforms including Webflow Cloud, Wix Vibe, and Stainless use Astro to help their customers create and publish websites. - These platforms run on or integrate with Cloudflare infrastructure while using Astro as their content and application foundation. ## Astro 6 Improvements Astro 6 is entering beta, with general availability expected soon. - A redesigned development server is built on Vite’s Environments API. - With the Cloudflare Vite plugin, local development can run in `workerd`, the Cloudflare Workers runtime. - Developers can locally use production-like APIs such as: - Durable Objects - D1 - KV - Agents - The Vite Environments API is not limited to Cloudflare; other JavaScript runtimes can provide similar integrations. - Live Content Collections are now stable, allowing content to update without rebuilding the site while retaining validation and caching. - Additional features include first-class Content Security Policy support, simpler APIs, and Zod 4 support. Cloudflare’s investment is intended to give Astro greater long-term support without changing its open, portable character. Developers can try the Astro 6 beta with `npm create astro@latest -- --ref next` or upgrade an existing project using `npx @astrojs/upgrade beta`.

astrocloudflarecloudflare-workersvite+4