WebAssembly를 통해 Cloudflare Workers에서 Caddy 실행

Source: Dev.to

소개

Hi folks. This is my first post. Happy to join you here :)

안녕하세요 여러분. 첫 글입니다. 여기서 여러분과 함께하게 되어 기쁩니다 :)

I’ve been running Caddy in production long enough to know two things: the Caddyfile is a joy to work with, and everything around it tends to get way more complicated than it should.

저는 Caddy를 프로덕션에서 충분히 오래 운영해 왔기에 두 가지를 알게 되었습니다: Caddyfile은 사용하기 즐겁고, 그 주변의 모든 것이 필요 이상으로 복잡해지는 경향이 있다는 점입니다.

For over a decade, the software‑engineering industry has been captivated by the containerization paradigm. You start with a clean Caddyfile on your laptop, then you add Docker for a $5 Virtual Private Server (VPS), then Helm charts, Terraform, or custom CI glue to get things into a Kubernetes cluster or edge platform. Suddenly, that elegant routing config is buried under YAML and infrastructure that mostly exists just to move the same HTTP rules between environments.

10년 넘게 소프트웨어 엔지니어링 업계는 컨테이너화 패러다임에 매료되었습니다. 노트북에 깨끗한 Caddyfile을 두고 시작해, $5 가상 사설 서버(VPS)를 위해 Docker를 추가하고, 그 다음 Helm 차트, Terraform, 혹은 맞춤형 CI 코드를 사용해 Kubernetes 클러스터나 엣지 플랫폼에 배포합니다. 그러다 보면 우아한 라우팅 설정이 YAML과 인프라스트럭처에 파묻혀, 동일한 HTTP 규칙을 환경 간에 옮기기 위한 수단에 불과하게 됩니다.

So, I asked a simple question:

그래서 저는 간단한 질문을 던졌습니다:

What if one Caddyfile could run on my laptop, on a cheap VPS, and on the infinitely scalable Cloudflare edge – without Docker, and without rewriting configs?

하나의 Caddyfile이 내 노트북, 저렴한 VPS, 그리고 무한히 확장 가능한 Cloudflare 엣지에서 Docker 없이, 설정을 다시 작성하지 않고도 실행될 수 있다면 어떨까요?

That question led to a profound architectural shift: compiling the Caddy web server directly to WebAssembly (WASM) and executing it natively on Cloudflare Workers.

그 질문은 근본적인 아키텍처 변화를 이끌었습니다: Caddy 웹 서버를 직접 WebAssembly(WASM)로 컴파일하고 Cloudflare Workers에서 네이티브로 실행하는 방식입니다.

Here is how bypassing the containerization trap entirely allows us to turn the edge into just another place Caddy lives.

컨테이너화 함정을 완전히 피함으로써 엣지를 Caddy가 살아갈 또 다른 장소로 만들 수 있는 방법을 소개합니다.

놓친 선택들

• Coolify VDS (Hetzner) – great when utilization is high, but for pet projects or low‑usage services the cost of idling outweighs the value. You also have to manage manual scaling.
  Coolify VDS (Hetzner) – 활용도가 높을 때는 훌륭하지만, 개인 프로젝트나 저사용 서비스에서는 유휴 비용이 가치보다 더 큽니다. 또한 수동 스케일링을 직접 관리해야 합니다.

• Cloudflare Containers – runtime is complex, cold starts are slow, and pricing isn’t free.
  Cloudflare Containers – 런타임이 복잡하고 콜드 스타트가 느리며, 가격이 무료가 아닙니다.

• AWS Lightsail & Google Cloud Run – excellent solutions but still require separate DNS/Domain/TLS management for “no‑infra‑config” setups, burning money at unbelievable speeds.
  AWS Lightsail & Google Cloud Run – 훌륭한 솔루션이지만 “인프라‑설정 없음” 환경에서도 별도의 DNS/도메인/TLS 관리가 필요하고, 믿을 수 없을 정도로 빠르게 비용이 소진됩니다.

V8 격리와 컨테이너

To understand how a monolithic Go application like Caddy can run on a serverless edge network, we have to look at the execution environment. Cloudflare Workers do not use containers or micro‑VMs. They are powered by workerd, an open‑source runtime built on Google’s V8 JavaScript engine.

Caddy와 같은 단일 Go 애플리케이션이 서버리스 엣지 네트워크에서 어떻게 실행될 수 있는지 이해하려면 실행 환경을 살펴봐야 합니다. Cloudflare Workers는 컨테이너나 마이크로‑VM을 사용하지 않습니다. 대신 Google의 V8 JavaScript 엔진을 기반으로 만든 오픈소스 런타임 workerd가 구동합니다.

The fundamental unit of execution here is the V8 isolate. When a request arrives, the V8 engine does not boot a Linux kernel, allocate a network namespace, or spin up control groups (cgroups). It simply allocates a memory context and executes the code.

여기서 실행의 기본 단위는 V8 isolate입니다. 요청이 들어오면 V8 엔진은 Linux 커널을 부팅하거나, 네트워크 네임스페이스를 할당하거나, cgroup을 생성하지 않습니다. 단순히 메모리 컨텍스트를 할당하고 코드를 실행합니다.

The era of the idle proxy server is ending.
One Caddyfile. Many runtimes.

유휴 프록시 서버 시대는 끝나가고 있습니다.
하나의 Caddyfile, 여러 런타임.

Full repository:

전체 저장소: