website VS ingress

Oh, just saw this. You wrote your comment while I wrote mine. If you can enumerate specifically what you want to see, please submit it to our issue tracker: https://github.com/caddyserver/website

Generally we encourage examples in our community wiki though: https://caddy.community/c/wiki/13 -- much easier to maintain that way.

Yes, the docs have been updated at https://github.com/caddyserver/website but haven't been deployed yet. There is a new protocols option:

    protocols h1 h2

Could you be more specific about these complaints? What examples don't work? We can't work on improving the docs if we don't get specific and actionable feedback. The docs are found at https://github.com/caddyserver/website if you want to propose any changes.

Protip: you can click almost everything in code blocks in the docs. For example, if you click `[]`, it brings you right to the request matcher syntax section, which explains what you can fill in there.

It would be redundant to write on every page what you can use as a matcher. The Caddyfile reference docs assume you've read https://caddyserver.com/docs/caddyfile/concepts which walks you through how the Caddyfile is structured, and it'll give you the fundamentals you need to understand the rest of the docs (I think, anyway).

If you think we need more examples for a specific usecase, we can definitely include those. Feel free to propose some changes on https://github.com/caddyserver/website, we could always use the help!

Caddy

That is true, unfortunately. We, the core maintainers, don't use k8s ourselves, so we need to defer to the community for help. See https://github.com/caddyserver/ingress

Caddy at its simplest form is an HTTP server. So you could use it to front end your application that otherwise isn't well suited for taking direct HTTP requests. Caddy would bring you other features like TLS support.

However I think in K8s world Caddy would make the most sense as an Ingress Controller. There is even a project as such: https://github.com/caddyserver/ingress

All traffic would terminate first at Caddy. Handling TLS, HTTP1/2/3, etc. Then passing it back to your application service/pod.

Sorry actually I'm mixing up caddy with traefik. And ingress is an http lb + something that talks to k8s to dynamically update the configuration. Caddy has a WIP ingress project https://github.com/caddyserver/ingress

We have an ingress controller in the works by the community here: https://github.com/caddyserver/ingress