在 Cloudflare Workers 上通过 WebAssembly 运行 Caddy

Source: Dev.to

引言

大家好。这是我的第一篇文章，很高兴加入这里 :)

我已经在生产环境中使用 Caddy 足够久，知道两件事：Caddyfile 使用起来非常愉快，而围绕它的所有东西往往会变得比实际需要的更复杂。

十多年来，软件工程行业一直被容器化范式所吸引。你从笔记本上一个干净的 Caddyfile 开始，然后为一个 5 美元的虚拟专用服务器（VPS）添加 Docker，接着使用 Helm chart、Terraform 或自定义 CI 代码把它们部署到 Kubernetes 集群或边缘平台。突然之间，那份优雅的路由配置被埋在 YAML 和基础设施之下，而这些基础设施大多只是为了在不同环境之间搬运相同的 HTTP 规则。

于是，我提出了一个简单的问题：

如果同一个 Caddyfile 能在我的笔记本、廉价的 VPS 以及无限可扩展的 Cloudflare 边缘上运行——无需 Docker，也无需重写配置，该怎么办？

这个问题促成了一次深刻的架构转变：将 Caddy Web 服务器直接编译为 WebAssembly（WASM），并在 Cloudflare Workers 上原生执行。

下面展示了完全绕开容器化陷阱，如何把边缘变成 Caddy 的另一个运行地点。

错失的方案

• Coolify VDS（Hetzner） – 当利用率高时很棒，但对于个人项目或低使用率的服务来说，空闲成本超过了价值。并且还需要手动管理扩容。
• Cloudflare Containers – 运行时复杂，冷启动慢，且费用并非免费。
• AWS Lightsail 与 Google Cloud Run – 方案优秀，但仍需为“无基础设施配置”场景单独管理 DNS/域名/TLS，花钱的速度惊人。

V8 隔离（Isolates） vs. 容器

要理解像 Caddy 这样的单体 Go 应用如何在无服务器边缘网络上运行，需要了解其执行环境。Cloudflare Workers 不 使用容器或微型虚拟机（micro‑VM）。它们由 workerd 提供动力，这是一款基于 Google V8 JavaScript 引擎的开源运行时。

这里的基本执行单元是 V8 isolate。当请求到达时，V8 引擎并不会启动 Linux 内核、分配网络命名空间或创建控制组（cgroups），它只会分配一个内存上下文并执行代码。

空闲代理服务器的时代正在结束。
一个 Caddyfile，多个运行时。

完整代码仓库：