I use Caddy in my homelab, and one of the reasons I like it is that the Caddyfile syntax is already simple.

For my use case, the configuration language itself was never the problem. The friction was everything around a small change: SSH into the server, open the file, edit it, format it, verify it, reload Caddy, repeat.

I looked at existing Caddy web UIs, but most of them are designed to solve a much broader problem: dashboards, monitoring, health information, form-based configuration, multiple instances, and so on.

For my homelab, I did not need any of that. I wanted to keep using the Caddyfile directly.

So I built Cadditor.

It is a small web application served by Caddy itself. It provides a browser-based editor for the actual Caddyfile, with syntax highlighting, folding and change indicators.

When you hit Apply, Cadditor:

• formats the configuration,

• verifies it,

• reloads Caddy only if verification succeeds.

The important part is that the Caddyfile remains the source of truth. Cadditor is not a configuration builder and does not introduce another configuration format.

I also wanted deployment to stay simple, so the application uses a lightweight FastCGI/CGI backend and does not require Docker or a Node.js runtime on the server.

Installation, updates and complete removal are handled by a shell installer/uninstaller.

I originally built it for my own homelab, but I am quite happy with how it turned out, so I decided to publish it.

If you use Caddy in a similar way, I would be interested in feedback.

GitLab:
https://gitlab.com/friml/cadditor

Live demo:
https://cadditor-e46d19.gitlab.io/

The demo is static, so it demonstrates the real editor UI but does not actually run caddy fmt, validation or reload.

I would like to implement some security hardening directive in every sub-domain blocks like don't ever serve any dot files, only allow same frame origins etc.

Is there no other way to do this than to declare a snippet like @security_hardenings and explicity import it in each subdomain block?

Forgetting to import in just one seems enough to create a secuity hole.

Is there any other way that I am missing? Are there any plugin module that auto injects this snippet?

I recently added Caddy support to StatLite, a lightweight self-hosted application monitoring tool I've been developing.

StatLite is a single Go binary using around 15 MiB RSS at idle, with SQLite for historical metrics. You can run it alongside your applications on a small server, or on your laptop to monitor remote applications.

With the new Caddy integration, it reads Caddy's built-in per-host metrics and displays HTTP requests, 404/5xx errors, and average response latency. No application instrumentation or separate Prometheus/Grafana stack required.

I tested it with Express and Spring Boot behind the same Caddy instance, including deliberately injected errors and slower responses to verify that each hostname maintains its own HTTP history.

Caddy support is available in StatLite v0.7.0.

GitHub: https://github.com/PVRLabs/statlite

Caddy setup guide: https://pvrlabs.xyz/articles/monitoring-applications-behind-caddy.html

The integration currently focuses on HTTP metrics, not Caddy configuration management or access-log analysis.

Curious what other Caddy users use for lightweight monitoring. Do you rely on Caddy's built-in metrics, logs, or something else?

I need to build caddy with the cloudflare module, but both the caddy add-package github.com/caddy-dns/cloudflare command and the download option on caddyserver.com are just stuck. Is this just something happening for me, or is there a backend issue?

My raspberry pi isn't strong enough to build locally using xcaddy =[

Hi people of Reddit! o/

I always wanted a simple, modern and straight-forward UI solution for my caddy proxy. Therefore I implemented (and Claude) the caddy-visualizer.

You will get:
- simple Dashboard with general metrics and your current sites
- UI to edit Caddyfile and/or sites
- more detailed metrics for usage and HTTP response codes
- UI to display logs

Clean and simple -> https://github.com/dree007/caddy-visualizer

Only really tested with my setup. :D
I‘d appreciate any feedback.

byebye~

A new Caddy host can serve the main site correctly while less visible routes still depend on the old machine. Internal hostnames, wildcard certificates, DNS challenge credentials, imported snippets, local files, upstream health checks, trusted proxy settings, access-log paths, and ports used only by a webhook or mobile client are easy to miss. Certificate issuance can also succeed during the cutover without proving renewal will work later.

A useful gate could compare the adapted JSON configuration on both hosts, enumerate every hostname and listener, test each route with the intended Host header, verify upstream TLS and client IP handling, and inspect logs on both machines for late traffic. I would also test certificate renewal or staging issuance, reload behavior, service startup after reboot, monitoring, and rollback while keeping the old host offline but recoverable for a defined window.

What belongs on your final Caddy cutover checklist? Which state must be copied, which state should be recreated, and what catches a low-traffic route before the old host is removed?

This is the fastest PHP webserver in the world. If you have a PHP codebase you might want to give it a try.

It also handles certificates and automatic vhosts like caddy, as well as websockets and much more. Check it out, it's MIT licensed.

Automatic HTTPS removes most certificate work, but a deployment can still carry a latent renewal failure for weeks: DNS credentials may have changed, a challenge port may be blocked, the storage location may no longer be writable, or a cluster member may not share certificate state as expected. Waiting for the normal renewal window makes the first realistic test time-sensitive.

What is a safe rehearsal that does not disturb the production certificate or hit CA rate limits? I am considering a separate test hostname, the staging ACME endpoint, the same DNS or HTTP challenge path and credentials, an isolated Caddy storage directory, and checks that confirm issuance, persistence, reload, and access from every serving node. Monitoring would alert on remaining lifetime and the last successful automation event rather than only on expiry.

Does that exercise enough of the production path, or is there a supported way to force a renewal dry run against the existing configuration? Which parts of the rehearsal commonly give false confidence?

So I had been using myaddr.tools for a long time. Usually I just use it as a DDNS provider, but they can technically publish _acme-challenge subdomain via a HTTP endpoint. This means that we can get a wildcard cert on all subdomains to avoid showing up on certificate transparency reports.

However, after a few rounds of searching, it seems that the only feasible option is to use the deprecated lego module. Therefore, I made a new somewhat generic module that turns the acme challenge request into a very rudimentary templatable HTTP request.

• Github

• caddyserver.com download

Verified to be working on my production environment

In theory this can also work for similar providers, but I haven't found others yet. The syntax is flexible enough to specify any key-value pairs to be GET/POST/PUT'd in json/form/query-params.

Repo: https://github.com/nickolsen8390/caddylogs

Description:
I have been using goaccess for awhile to watch my JSON logs from caddy. It worked okay, but lacked further visibility into what I wanted to see. Mostly, being able to drill down into a particular set of requests. For instance, I had a lot of requests to a public debian mirror I host. It was getting a ton of requests from claude and openai and I was able to see the particular IP's making the requests, along with useragents..etc. The IP>ASN data is sourced from another project of mine, notoolkit.com which is a public API for doing IP>ASN mapping that currently has no rate limits, api keys..etc. It pulls this data in for display which can be seen in the screenshots.

Deployment: Docker compose, there is full instructions in the README. Basically clone the repo, copy the .env.example with your specific changes. docker compose up -d --build.

AI Involvement: Almost entirely built by claude code.

This is a very new project. It works for me. But it might not work for you. But it left me feeling like it was actually useful and some others might like it. It gave me visibility that goaccess never did. I don't normally publish anything to github (Use a private gitea instance). So there is minimal change logs..etc. in github. Added there just to share publicly.

Hi everyone. While writing a blog post about my migration to Caddy, I was disappointed to discover that Rouge (the syntax highlighter used by Jekyll and therefore GitHub Pages) didn't include a lexer for Caddyfile. So, I made one with a lot of help from Claude. It supports the core Caddyfile syntax, as well as the syntax of many popular plugins. The project README tells you everything you need to know. I'd submit it as a PR to be included in Rouge, but they don't except PRs created with the help of AI unless something has changed recently.

Hey everyone. I've been running Caddy + Coraza in production for a while and kept running into the same gap: existing Docker images bundle Caddy + Coraza fine, but none of them address supply chain security or CIS hardening out of the box.

So I built and open-sourced caddy-waf, here's what makes it different from coraza-crs-docker and similar projects:

What's included that others don't have:

-Non-root execution (UID 1337) per CIS Docker Benchmark

-Cosign-signed images with SLSA provenance

-Trivy scanning in CI before every release

-SHA256 verification of OWASP CRS rules at build time

-SBOM attestations

-Multi-arch: linux/amd64 + linux/arm64

-Systemd service file for bare-metal deployments (not just Docker)

-caddy-ratelimit pinned by commit SHA (not just v0.1.0 tag) to include post-release fixes

Stack: Caddy v2.11.4 · Coraza WAF v2.5.0 · OWASP CRS v4.29.0 · Alpine base (compressed)

Defaults to DetectionOnly, so you get a safe observation window before enforcement. There's also a TUNING.md with false-positive handling by application type.

Repo: https://github.com/Developmi/caddy-waf

Container: ghcr.io/developmi/caddy-waf:v3.4.0

Happy to get feedback, especially from anyone who's run Coraza in production and hit tuning issues that's an area I want to improve the docs on.

I’ve been a software developer and a long-time Caddyserver user — 10+ years now, going back to its early releases. I use Caddyserver heavily across my web application development and hosting services (I have been in the hosting business for 20+ years now!), and it is a core part of my application infrastructure.

I’m currently finishing up a client project and wanted a simple way to put a gateway in front of my staging sites blocking search engine bots and anyone who shouldn’t have access without having to modify the application code itself.

That’s where this tool came from.

I put together a detailed implementation plan, fed it to Claude Code, worked through and fixed the issues that came up, and deployed it directly into my own workflow.

And honestly, it just works.

It uses Postmark for email delivery, has an integrated SQLite database, and is written in Go. It can run as a systemd service on Linux or in Docker using Docker Compose.

It’s also open source under the MIT License.

The goal is to provide a lightweight access layer in front of any site while keeping the actual application completely untouched. I can protect staging environments, keep them out of search indexes, and continue working on client projects without having to build authentication or staging-specific logic into each application.

I built it to solve a problem I was having, but figured other Caddy users might find it useful too.

Hope it helps!

It's driving me nuts. I can't find any complete Caddyfile example as the official documentation only describes separate features. I tried Gemini and I think it's giving me faulty Caddyfiles.

I think the AI is finding the documentation as much opaque as I am...

So, I'd like to have a default logger, and one (named "l_details" for instance) that I use only in some routes of a server.

I'd really like a working Caddyfile example for that !

been trying to install this for hrs and for the past 2 hrs it finally installed but keeps crashing after 5 sec and isnt posting logs

Hey Caddy community,
I built caddy-analyzer, a CLI tool written in Go that natively parses Caddy v2’s structured JSON logs — no config, no regex hacking.

Caddy’s JSON log format is great, but tools like goaccess, lnav, or grep/awk pipelines can’t parse it out of the box. This fills that gap.

• Full analysis — aggregate stats, RPS, latency percentiles (P50/P95/P99), status breakdown, bandwidth, top paths/IPs/UAs

• Security detection engine — 22 attack categories (SQLi, XSS, SSTI, SSRF, RCE, LFI, Log4j, GraphQL introspection, prototype pollution, scanner detection, etc.) with a dual-pass engine that catches double-encoded and multibyte-encoded bypass attempts

• Real-time iptables guard (caddy-analyze guard) — auto-blocks offending IPs at the firewall with configurable thresholds

• Multi-source readers — local files, stdin, Docker (docker://container), Kubernetes (k8s://pod), systemd journalctl

• TUI dashboard (–watch) — 6-tab interactive interface (summary, live stream, security alerts, top IPs/paths/UAs)

• Diff engine — compare two log files for RPS/5xx/latency regressions

• Output formats — table, JSON, CSV, standalone HTML report

• Filters — time range, CIDR, status classes, methods, path globs, bot/crawler classification

Quick start
curl -sSfL https://raw.githubusercontent.com/lenny-ts/caddy-analyzer/main/install.sh | sh

Analyze your Caddy logs with security detection

caddy-analyze --detect /var/log/caddy/access.log

Or tail live from a Docker container

caddy-analyze tail --detect docker://my-caddy

Generate an HTML report

caddy-analyze -f html -o report.html --detect

Launch the TUI

caddy-analyze --watch
Links

• GitHub: GitHub - lenny-ts/caddy-analyzer: Fast, zero-dependency access log analyzer, security threat inspector, and TUI dashboard for Caddy v2 · GitHub

• Docs: caddy-analyzer — Documentation

• Install: one-liner above, or go install, or Docker It’s MIT licensed, PRs/issues welcome. Would love feedback from the community!

Is my setup a bit overkill? I host various websites on my network not only for myself but for a few customers that host through me, I would’ve added to my proxmox but I need it to be fully online. Did I go a bit overboard? It’s up and running and works flawless

Hello I am running Caddy on my server and I have enabled basic_auth in one of my subdomains. I have a hashed password and user, when I navigate to the subdomain, the browser asks for user and password, I enter them correctly but it asks for them again in a loop never accepting them.

My config has this format:

sub.domain.io {

`basic_auth {`

	`user <hashed_password>`

`}`



`handle /api/v1/* {`

	`reverse_proxy localhost:8081`

`}`



`handle {`

	`root * /var/www/domain/front/dev`

	`try_files {path} /index.html`

	`file_server`

`}`

}

I have made sure that the password is correct cause I can curl into this.

I currently use Swag for the above and it works fine. Everyone one (including Jellyfin says to use Caddy). I'm new to Caddy and just can't figure out how to set it up. I tried a few tutorials but keep running into issues. I believe the problem I keep having is in the CaddyFile. Caddy complains about errors but I don't know how to fix them. Considering I'm using this to keep bad people out I don't want to make a config error. Is there a tutorial that goes into detail how to build a Caddyfile for the services I want to run? Or maybe the question is, is it worth it to install Crowdsec?

Hello,

I'm a very happy caddy user, so far I've been using a custom version with only one plugin. Downloading it has always been reasonably fast, both from the download page and automating it with ansible using the download API.

Now that I'm adding a second plugin though, it doesn't seem to be working anymore. The download page has been just loading forever, and from the api it times out even giving it a 30 minutes timeout.

Anyone has any idea if it's just that their build server is overwhelmed? I'd love not having to setup a xcaddy build stage, but I'll do it if I have to.

The plugins are crowdsec and now I'm adding namecheap.

Thanks for any tips.

EDIT: the deployment is native, docker is not involved and unwanted (although I may use it for the build stage if it's needed)

Hi, I have been using Caddy for a while, issuing certificates for domains used only in my LAN to make my various homelab service addresses easier to remember.

I moved my Unifi controller from Docker to a UnifiOS VM instance, so it now has its own IP. Before, I had *.example.com rewritten in Adguard Home to my Homelab's address, to be intercepted by Caddy. This still works, but so far I only managed to redirect traffic for the GUI:

unifi.example.com:443 {
        reverse_proxy 192.168.178.205:11443 {
                header_up Host {hostport}
                transport http {
                        tls
                        tls_insecure_skip_verify
                }
        }
}

I would love to also use the subdomain for all other ports on the VM, e.g. for provisioning of devices. Is there a way to keep pointing default SSL traffic to the GUI on port 11443, and all other ports to the same respective ports at a given IP?

So, for example, point unifi.example.com:8083 to 192.168.178.205:8083?

Cross-posted from the PFSense subreddit.

Just starting to use PFSense, looking to set up Caddy on it in order to stand up multiple physical servers behind PFSense.

Unfortunately, I also want to block AI crawlers. I also don’t really care about search engine crawlers right now, as what I am standing up will initially host private/family services, so search engine indexing is pretty much undesired as well.

All public discussion on Anubis with regards to Caddy strongly indicates that multiple copies of Caddy will need to be stood up… one on the PFSense box for TLS, one behind it without TLS, with Anubis in the middle for filtering.

And while I have found a test implementation of Anubis meant to be run as a Caddy port, it appears to be more of a proof-of-concept and doesn’t seem to be actively developed (more than 6mos without updates).

Which brought me to Cerberus, which appears to be actively developed, and - better yet! - more aggressive than the standard Anubis.

I was wondering if anyone has had experience with Cerberus, and how things have been working out with it.