---
title: "How Caddy Serves a Static Site: The Request Flow"
description: "See how Caddy handles a request for a static site, from DNS resolution through container routing to file_server, and how TLS and redirects fit into the flow."
---

# How Caddy Serves a Static Site: The Request Flow

**Type:** [How it works](https://yomu.fyi/visual-explainers/category/how-it-works.md)

![A numbered vertical flow diagram showing a client request going through DNS, a platform edge, a Caddy container, site matching, a redirect branch, and file\_server, with side panels for the build pipeline and TLS certificate management.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/fb1f0ba5-6e7e-4c53-8f79-396868e7d7b1/image-ea878f8c-37f0-408e-a00f-46d48966dc07.webp)

> See how Caddy handles a request for a static site, from DNS resolution through container routing to file\_server, and how TLS and redirects fit into the flow.

## Explanation

Caddy is a web server that reads a configuration of site blocks to serve files or proxy requests. In a typical static-site deployment, a client request hits DNS, resolves to a platform edge, gets routed to a Caddy container, and is matched against a site block. Caddy then applies redirects and serves the file with file\_server. In the Hugo-on-Fly example, automatic HTTPS is disabled because the platform handles certificates. Understanding this flow helps you debug where a request is actually handled and decide which layer should own TLS, DNS, and file serving.

## FAQ

### Why would you disable Caddy's automatic HTTPS?

In the Hugo on Fly example, auto\_https is disabled because Fly handles certificate management. Fly's edge terminates TLS and requests Let's Encrypt certificates via DNS validation using flyctl certs. Disabling Caddy's auto\_https avoids duplicate certificate management and lets the platform own TLS.

### How does Caddy know which site to serve when multiple domains point to the same container?

Caddy uses site blocks in its configuration. Each block matches a hostname, such as makeroni.cc or the old fly.dev hostname. When a request arrives, Caddy matches the Host header to the appropriate block and applies its directives, like file\_server or a redirect.

### What is the role of the multi-stage Docker build in this Caddy deployment?

The Hugo post uses a multi-stage Docker build to first generate the static site with Hugo and then copy the output into a Caddy image. This keeps the final image small because it only contains Caddy and the static files, not the Hugo build toolchain. The resulting image is deployed to Fly.

**Tags:** [Caddy](https://yomu.fyi/topic/caddy.md), [DNS](https://yomu.fyi/topic/dns.md), [Docker](https://yomu.fyi/topic/docker.md), [Fly](https://yomu.fyi/topic/fly.md), [Hugo](https://yomu.fyi/topic/hugo.md), [TLS](https://yomu.fyi/topic/tls.md)

## Related reading

### [Build a multi-tenant platform with OpenShift Dev Spaces](https://yomu.fyi/post/build-a-multi-tenant-platform-with-openshift-dev-spaces.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Ajay Kanse
- Published: Oct 9, 2026
- Type: Tutorial

Local developer workstations introduce three concrete operational risks: production-parity risk from environment drift, slow time-to-first-commit for new engineers, and unmanaged security exposure from misconfigured tools. Red Hat OpenShift Dev Spaces addresses these by moving compute and tooling into containerized workspaces running directly on the cluster, with environments declared as code in a devfile. A production deployment requires four-zone namespace isolation separating control (openshift-devspaces), core server (devspaces-checluster), secure asset (devspaces-openvsx), and sandbox (username-devspaces) zones to prevent operator reconciliation from overriding custom configurations. Resource governance uses a two-tier model with defaultContainerResources fallback limits and containerResourceCaps absolute per-container ceilings, while automated cleanup cron jobs (monthly on the 1st) and inactivity idling (after 4 hours) protect etcd health by removing stopped workspaces after 30 days. The guide concludes with next steps for authentication and private extension registries.


### [Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects](https://yomu.fyi/post/introducing-on-demand-cpu-and-memory-profiling-with-flamegraphs-for-wo.md)
- Company: [Cloudflare](https://yomu.fyi/company/cloudflare.md)
- Author: Dominik Picheta
- Published: Oct 9, 2026
- Type: Announcement

Cloudflare introduced on-demand CPU and memory profiling for Workers and Durable Objects, accessible via the CLI or the Dashboard’s Observability page. Users can generate interactive flamegraphs and download pprof files, with each rectangle’s width representing CPU time or memory usage over a chosen duration. Profiling the R2 binding Worker revealed that genericR2JsonReplacer, called by JSON.stringify, processed nested values multiple times; fixing it made the function 2.7x faster. A different Worker with P999 memory at 133 MB (above the 128 MB limit) was found to have a partially enabled Prometheus code path accounting for 66.7% of allocations; disabling it reduced P999 memory to 118 MB and eliminated out-of-memory errors. The profiling system locates the correct data center and isolate for the Worker or Durable Object, and continuous profiling is being developed to automatically capture samples without manual initiation.


### [Deno is joining Cloudflare](https://yomu.fyi/post/deno-is-joining-cloudflare.md)
- Company: [Cloudflare](https://yomu.fyi/company/cloudflare.md)
- Author: Ryan Dahl
- Published: Oct 9, 2026
- Type: Announcement

The Deno team is joining Cloudflare to merge workerd and celld, aiming to make self-hosting Workers and Durable Objects radically simpler for developers. Ryan Dahl, creator of Node.js and Deno, explains that Durable Objects provide a powerful abstraction: a distributed singleton with a SQLite database that scales by sharding state and WebSocket connections across machines. He started celld to run this model outside Cloudflare with a single Rust binary and object storage as its only external dependency. Kenton Varda counters the theory that Workers’ unique design creates lock-in, noting that workerd is open source and that celld provides an escape hatch for migration. The merged effort, led by Ryan and Bert Belder, will make self-hosting a first-class supported way to build and run apps using the Workers programming model.


### [3 Tips on Using Ngrok to Maximize Messenger Apps](https://yomu.fyi/post/3-tips-on-using-ngrok-to-maximize-messenger-apps.md)
- Company: [Intercom](https://yomu.fyi/company/intercom.md)
- Published: Oct 9, 2026
- Type: Tutorial

Ngrok is a tool that creates public URLs to expose a web server on a development machine, enabling developers to set webhook URLs while building Messenger Apps for Intercom without external infrastructure. To start, run ‘ngrok http 3000’ to tunnel a local server; the free version limits sessions to eight hours and generates a new address each run. The ngrok web interface at http://localhost:4040 allows inspection of HTTP traffic, showing request and response details. Developers can replay requests with the Replay button to avoid manually re-triggering endpoints during testing. The interface also validates JSON formatting in request and response bodies, highlighting errors like missing quotes for debugging.


### [Hugo's There - Flying with Hugo and Caddy](https://yomu.fyi/post/hugo-s-there-flying-with-hugo-and-caddy.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Jul 21, 2020
- Type: Tutorial

A new community venture’s website is built with Hugo, served by Caddy, and deployed on Fly, with a custom makeroni.cc domain added after the initial deployment. The process initializes a Fly app on port 80, uses Hugo’s Quickstart and Ananke theme, and employs a multi-stage Docker build based on klakegg/hugo:0.74.0-onbuild, copying generated files into caddy:2.1.1. Caddy serves the static files with file\_server while auto\_https is disabled because Fly handles certificate management; separate rules serve makeroni.cc and redirect the old fly.dev hostname. DNS A and AAAA records connect the domain to Fly, and flyctl certs create requests a Let’s Encrypt certificate through DNS validation, leaving the site ready to serve securely after redeployment.