The Caddy image packages the Caddy HTTP server binary, its module loader and enabled modules (reverse proxy, static file server, TLS automation, logging), the TLS stack, and a minimal runtime filesystem and config locations. It exposes the JSON config API and standard ports; runtime artifacts include certificate storage, OCSP stapling cache, and plugin binaries.
In containerized and production environments it runs as a single-process container managed by orchestration or as an ingress/edge proxy, TLS terminator, or static content server. Configuration can be provided via mounted JSON/Caddyfile, environment variables, or the runtime API, and it supports hot config reloads without restarting the process.
Teams evaluate a Caddy hardened image for regulated environments because hardened images reduce attack surface (fewer packages, non-root runtime, filesystem restrictions), enable reproducible builds and vulnerability scanning, and enforce stricter defaults for permissions and syscall filtering.
The Minimus Caddy image is designed differently from typical Caddy container images by being built from scratch with only the essential components and runtime artifacts, omitting package managers, shells, and unnecessary libraries to minimize the attack surface. That minimal footprint makes the image faster to start, lighter to distribute, and easier to maintain and audit, while simplifying dependency management and vulnerability exposure compared to full distro-based images.
The Minimus hardened Caddy image goes further by applying hardening and configuration controls aligned with industry standards such as NIST SP 800-190 and CIS Benchmarks—secure defaults, reduced privileges, capability drops, tight filesystem permissions, and reproducible builds—to support operational security and compliance for engineering and security teams.
A Caddy container is a runnable, isolated instance of the Caddy web server packaged as a container image. It runs in a container runtime such as Docker or Kubernetes and includes the Caddy binary, configuration, and data volumes managed by the container.
These images are typically pulled from a registry as a single image named after the project. For enhanced security, use a hardened Caddy image, which applies security best practices and reduces attack surface.
Example run:
docker run -d -p 80:80 -p 443:443 -v caddy_data:/data -v ./Caddyfile:/etc/caddy/Caddyfile caddy:latestCreating a docker image standardizes the runtime environment by packaging application code, dependencies, and config into a single artifact. It enables portable deployments across hosts, clouds, and CI pipelines, and supports reproducible builds through versioned layers. Images cache work, speeding up builds and rollbacks by tagging releases. They also limit drift by isolating the application from the host, improving security and stability.
Security and operations benefit from minimizing layers, pinning dependencies, and scanning for updates. A hardened Caddy image reduces attack surface and drift, and pairs well with CI checks, image signing, and deployment guards for trustworthy, repeatable releases.
FROM alpine:3.18
RUN apk add --no-cache curl
Caddy is a modern web server and reverse proxy that emphasizes simplicity and security. It automates TLS certificates, supports HTTP/2 and HTTP/3, and can serve static sites, proxy APIs, and route traffic to backend services.
In container deployments, use the hardened Caddy image to run the server behind a TLS-enabled proxy.
docker run -p 80:80 -p 443:443 -v /site:/usr/share/caddy -v /site/Caddyfile:/etc/caddy/Caddyfile caddy:latest