【免费下载链接】awesome-cloudflare-selfhosted☁️ Open-source* apps that replace SaaS product tools, running in your own Cloudflare account项目地址https://gitcode.com/gh_mirrors/aw/awesome-cloudflare-selfhosted点击查看免费下载awesome-cloudflare-selfhosted 是一个收录「运行在你自己 Cloudflare 账号里的开源应用」的清单项目。它的核心卖点不是数量而是每条信息都经过审计scripts目录下的工具链会逐个打开每个项目的仓库自动读取 wrangler 部署配置和许可证文件——许可证、bindingsD1 / R2 / KV 等都不是项目自报的而是从仓库里读出来的。这篇指南带你完整看懂这套审计机制。为什么需要审计清单里的信息不能照抄自述普通的 awesome 清单依赖提交者自己填写描述很容易出现两类问题信息漂移项目换了许可证、删掉了部署配置清单却迟迟不更新自报不准README 里说用了 D1 R2实际配置里可能只是注释占位符。这个项目的答案是data/目录是唯一真相源而审计工具负责核对data/与真实仓库是否一致。每个项目对应一个带 frontmatter 的数据文件例如 data/entries/punctual.mdname: Punctual repo: CCCrafts/punctual category: business-and-operations license: MIT bindings: [D1, R2, KV, Durable Objects, Queues, Cron] summary: Calendly alternative for a single team...其中license和bindings两个字段正是审计机制的重点核查对象。详细原理记录在官方文档 docs/auditing.md 中。scripts 工具链一览6 个脚本各司其职脚本职责scripts/data.js数据加载器解析 frontmatter、加载分类与条目、渲染 README 表格行scripts/audit.js审计主程序把每个条目与它的 GitHub 仓库逐项核对scripts/config-parser.js核心解析器从部署配置中提取 bindings、分类许可证纯函数无网络依赖scripts/propose-entry.js从提交 issue 自动生成条目或列出拒绝理由scripts/issue-entry.js解析与校验 issue 表单、渲染条目文件scripts/refresh-popular.js每月刷新popular标记⭐1000 星阈值徽章高亮配合三套测试文件config-parser.test.js、data.test.js、issue-entry.test.js整个工具链是零依赖的纯 Node 程序——无需npm install装好 Node 20 就能跑。各命令定义见 package.json。审计许可证直接读 LICENSE 文件不信任分类器许可证检查的核心逻辑在 audit.js 的inspectRepo函数 中流程分四步拉取仓库元数据通过ghCLI 读取仓库信息含 GitHub 识别的 SPDX 许可证遍历文件树找到根目录下的LICENSE/LICENCE/COPYING文件亲自读文件内容只有当 GitHub 没识别出许可证或识别为NOASSERTION时才读取许可证正文前 4000 字符交给classifyLicense做文本分类核对声明把仓库实际许可证与条目里声明的license:对比不一致就报问题——entry says MIT, repo says BUSL-1.1。classifyLicense依赖一张 LICENSE_TABLE 对照表把许可证正文里的关键措辞映射到 SPDX 标识符正文特征识别为mit license / permission is hereby grantedMITapache licenseApache-2.0gnu general public licenseGPL-3.0server side public licenseSSPLall rights reserved兜底项Proprietary注意一个精心设计的顺序问题All rights reserved. 这句话原样出现在 BSD 许可证正文里所以专有许可证的兜底匹配必须放在所有已知许可证之后执行否则 BSD 项目会被误读成自定义条款。这类每个规则都来自一次真实误判的设计思路贯穿整个解析器。识别 wrangler 配置17 种 bindings 的自动扫描确认项目确实部署到 Cloudflare是收录标准之一。审计器如何判断第一步找到部署配置文件。WRANGLER_RE 正则 会匹配wrangler.toml/wrangler.json/wrangler.jsonc以及.example、.template、.ci等变体很多项目提交的是示例配置真实 id 留空。与此同时deployConfigs 函数 还会排除old/、legacy/、tests/、examples/这类描述别的东西的目录——但保留了兜底逻辑如果项目的真实部署配置恰好就在templates/下比如 kukuroo宁可退回使用也不误判它无法部署。第二步从配置里提取 bindings。BINDINGS 表 定义了 17 种 Cloudflare 资源的识别规则D1、R2、KV、Durable Objects、Queues、Workers AI、AI Gateway、Vectorize、Workflows、Email、Analytics Engine、Browser Rendering、Hyperdrive、Images、Pipelines、Containers、Cron。每个条目 frontmatter 里的bindings: [D1, R2, KV...]就是这么来的——审计结果才是这些列表的事实来源README 每行的·分隔列表以它为准。特别处理Alchemy 项目。部分项目用 Alchemy 框架在alchemy.run.ts里用 TypeScript 声明基础设施仓库里根本没有wrangler.toml。如果只查 wrangler 文件这些往往是该领域最大的项目会被误判为无法部署。所以解析器为 Alchemy 维护了一套独立的 ALCHEMY_BINDINGS 规则按D1Database(...)、R2Bucket(...)等资源构造器匹配。第三步找一键部署按钮。审计器还会读取仓库 README匹配 Deploy to Cloudflare 按钮链接deploy.workers.cloudflare.com/?url...命中的条目就会在清单里标注 ⚡ 1-click deploy。另外两个保活检查也很直白仓库超过365 天没有提交 → 报no commits in N daysSTALE_DAYS仓库被归档 → 报repository is archived。解析配置的四个经典陷阱读一个配置文件为什么需要写 300 多行代码因为真实世界里的 wrangler 配置处处是坑。config-parser.test.js 里的每个测试用例都来自一次真实误判路径通配符伪装成块注释配置值/fonts/*或/api/*里的/*长得就像注释开头。正则处理会把整段文件吞掉直接抹掉后面的所有 bindings——punctual 和 OmniMail 的整个配置就曾因此消失。解决方案是 splitComments 手写了一个逐字符扫描器区分字符串、行注释、块注释而不是简单套正则。wrangler init的脚手架注释wrangler 初始化时会在配置里列出所有可用 binding 的注释占位每个都挂着官方文档链接。照单全收等于给项目安上它从未用过的 Vectorize 和 Hyperdrive。解析器会识别这种带文档链接的注释块并丢弃它。注释掉的 binding 恰恰是真的项目经常把# [[d1_databases]]注释起来让部署者填上自己的database_id。这种 binding 是项目真实使用的——所以注释不能简单全部删除。上面两个陷阱的平衡点是只丢弃打广告的脚手架注释段保留项目自己写的注释。TOML 与 JSON 语法差异TOML 声明队列是[[queues.producers]]表头后面没有JSON 则是queues: [...]后面有。只按 JSON 形状写规则会把 codeseer 的 KV Queues 审成只有 KV。许可证分级报告条款、标记风险但从不拒绝识别出 SPDX 标识符之后licenseStatus 函数 把许可证分为四级状态含义清单上的表现open知名开源许可证MIT、Apache-2.0、GPL-3.0 等 30 余种白名单灰色徽章source-available源码可用但带附加条件BUSL、FSL、PolyForm、SSPL 等⚠️ 橙色徽章none没有许可证文件默认版权保留⚠️ 橙色徽章unrecognised其他交给人工判断原样展示关键设计哲学是分级只负责标记从不负责拒绝。项目不会因为使用 BUSL-1.1 而被移出清单——这类许可证通常只限制与授权方商业竞争自用自托管是被允许的。CONTRIBUTING.md 里解释了这条规则的历史演变而SOURCE_AVAILABLE_LICENSES和RECOGNISED_LICENSES两个集合只驱动徽章颜色别无他用。从提交到收录propose-entry 的自动化流程同一套解析能力也被复用在提交审核环节。propose-entry.js 在新项目提交时自动执行解析 issue 表单仓库地址、分类、一句话简介检查重复收录、slug 冲突调用inspectRepo读取仓库是否归档、是否超过 12 个月没提交、是否存在部署配置全部通过 → 自动生成data/entries/slug.mdlicense 与 bindings 直接取自审计结果连 ⭐1000 星的popular标记也顺手写好任何一项不过 → 一次性列明所有拒绝理由。机器能判定的全部自动化它是否真的是 SaaS 替代品而不是框架这类判断则留给维护者。本地运行一次完整审计想自己跑一遍克隆仓库需 Node 20 与已登录的ghCLIgit clone https://gitcode.com/gh_mirrors/aw/awesome-cloudflare-selfhosted cd awesome-cloudflare-selfhosted npm run audit # 逐条审计所有条目 npm run audit:stale # 只看 12 个月以上无活动的条目 npm run audit -- --json # 机器可读输出 npm test # 运行解析器测试 npm run popular # 刷新 popular 标记审计结果会写入根目录的.audit-cache.json缓存重复运行不会重复请求 API删除该文件即可强制全新抓取。有问题的条目会以项目名 问题列表形式输出例如entry declares a license but the repo has no license file、no deploy config found (wrangler or alchemy)——退出码非 0 表示存在被标记条目方便接入 CI。小结awesome-cloudflare-selfhosted 的审计机制可以浓缩成三句话数据驱动data/是唯一真相源README 由数据生成改页面不如改数据读仓库而不是信描述许可证读自 LICENSE 文件、bindings 读自 wrangler / Alchemy 配置17 种资源逐一核对零依赖 全测试纯 Node 脚本解析器的每条规则背后都是一个被修复的真实误判。这套机制保证了清单里每个 ⭐ 徽章、每个许可证标记、每条 binding 列表都是读出来的而不是抄出来的——这正是它区别于普通 awesome 清单的地方。赞分享【免费下载链接】awesome-cloudflare-selfhosted☁️ Open-source* apps that replace SaaS product tools, running in your own Cloudflare account项目地址https://gitcode.com/gh_mirrors/aw/awesome-cloudflare-selfhosted点击查看免费下载相关推荐自托管安全必读awesome-cloudflare-selfhosted 如何审计许可证风险与标记项目完整指南自托管安全必读awesome cloudflare selfhosted 如何审计许可证风险与标记项目完整指南 在自托管软件时许可证风险往往是最容易被新Cloudflare Wrangler CLI 安全实操指南解读 agent-scripts 中 wrangler 技能的设计与实战要点Cloudflare Wrangler CLI 安全实操指南解读 agent scripts 中 wrangler 技能的设计与实战要点 本文以开源仓库 agMac Mouse Fix 完整指南按键映射与智能滚动4 步把闲置鼠标变成第二块触控板Mac Mouse Fix 完整指南按键映射与智能滚动4 步把闲置鼠标变成第二块触控板 Mac Mouse Fix 是一款开源的鼠标增强应用靠按键映射和智桌面应用系统编程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考