[HN Gopher] Show HN: Caddy 2
___________________________________________________________________
Show HN: Caddy 2
Author : mholt
Score : 406 points
Date : 2020-05-04 17:07 UTC (5 hours ago)
(HTM) web link (caddyserver.com)
(TXT) w3m dump (caddyserver.com)
| throwaway483284 wrote:
| I've started using caddy 2 couple of days ago, I am using
| Caddyfile because json based configuration looks really awful and
| is hard to maintain (quick changes take a lot of time). The only
| problem I've encountered is that you can't turn off TLS for a
| route using Caddyfile. Why is that?
| mholt wrote:
| You definitely can, just prepend your site address with http://
| or use port :80 (the HTTP port).
|
| More info:
|
| - https://caddyserver.com/docs/caddyfile/concepts#addresses
|
| - https://caddyserver.com/docs/automatic-https#overview
| bueny wrote:
| Will there be a time when performance will be relevant for Caddy?
| mholt wrote:
| Is it too slow for you?
| bueny wrote:
| In comparison with other webservers it is slower. For me it's
| okay but metrics!
| stackola wrote:
| You accidentally a word or two here:
|
| > If the latest OCSP staple indicates that a revocation, Caddy
| automatically replaces the certificate with a new one.
| mholt wrote:
| Ha, oops. Thanks.
| Tomte wrote:
| Does Caddy request separate certificates for domains served
| through it, or is it handled using SANs?
| mholt wrote:
| Both, technically.
|
| CommonName has been deprecated for years, so all of Caddy's
| certificates (and all of Let's Encrypt's) are SAN certificates.
| Caddy manages single-SAN certs, in accordance with recommended
| best practices: https://docs.https.dev/acme-ops#use-one-name-
| per-certificate
|
| (We learned from experience that single SAN scales better and
| is less prone to troubles. For example, Caddy sites were not
| affected by the recent Let's Encrypt revocation incident
| because it manages only single-SAN certificates. And frankly,
| that shouldn't matter since you don't have to manage them.)
| Tomte wrote:
| Ah, TIL.
|
| I was asking because right now my nginx/certbot setup
| requests a single certificate for all my domains, and I would
| like to have them separate.
|
| (I'm sure you can do that with certbot, I just haven't
| tweaked my setup, yet)
| mholt wrote:
| I see. Yeah, I think CertBot does that because of
| limitations in Apache (and possibly nginx as well) with
| "virtual hosting".
|
| So yeah, Caddy uses one name per certificate by default,
| and there's no way to change that.
| [deleted]
| sqs wrote:
| Awesome! We use Caddy at Sourcegraph
| (https://sourcegraph.com/search?q=caddy+repo:%5Egithub%5C.com...)
| and love it. Caddy makes it much easier to run our app in local
| dev (with HTTPS and other nice things).
| narrationbox wrote:
| Same here! We are huge fans of Caddy at Narration Box
| (https://narrationbox.com) and we are considering replacing
| NGINX completely in our Django production stack. (Currently we
| only use Caddy for development and staging) The author of
| Caddy, Matt Holt, is a really great person and is extremely
| responsive on Twitter and GitHub. Highly recommend checking
| them out.
| mholt wrote:
| Thank you for your feedback and support!
|
| I haven't actually heard of Narration Box before now, but it
| looks fantastic!
|
| I'm also a huge fan of Sourcegraph (@sqs if you're reading
| this!) -- which has really helped Caddy get to this point.
| poulsbohemian wrote:
| I'm really curious your reasons / why you like Caddy over
| Nginx. Thoughts?
| narrationbox wrote:
| Nginx requires too much configuration. It is very brittle
| if you do not have a full time DevOps person monitoring
| things. E.g. for production web apps, take a look at the
| amount of tooling that has been developed to manage Nginx:
|
| https://www.digitalocean.com/community/tools/nginx
|
| https://github.com/yandex/gixy
|
| This is not a criticism of Nginx per se, it comes from a
| time when Apache is the only other alternative and end-user
| UX is hardly priority. An analogy would be systemd and pm2,
| pm2 have few advantages over systemd on paper but in
| practice it has a much more pleasant UX and saner defaults
| even though it requires a separate installation on most
| servers while systemd is available by default. It is the
| difference between Heroku and AWS. For the 99th percentile
| of efficiency Nginx still beats Traefik and Caddy, but
| sometimes scaling servers is cheaper than hiring DevOps
| staff.
| stjo wrote:
| As a webdev noob, the amount of simple and powerful features is
| astonishing. Just look at that:
| https://caddyserver.com/docs/caddyfile/directives/reverse_pr...
|
| Thousand line nginx config files reduced to nothing. You can
| literally run it "configured" from the command line.
| zzzcpan wrote:
| But this is pretty much at the level of nginx config, except
| that nginx had more time and has more features and more
| flexibility because of that.
| xrisk wrote:
| Slightly disappointed because they changed the Caddyfile syntax.
| I think it's a bit more verbose now, compared to v1.
| mholt wrote:
| Some parameters might have one or two more words to type, but
| the growth in flexibility is enormous, and we felt it was worth
| the tradeoff. You can see a comparison here:
| https://caddyserver.com/docs/v2-upgrade#caddyfile
|
| We also think _slightly_ more verbosity in the v2 Caddyfile is
| actually a good thing. Aside from more flexibility, it makes it
| a little clearer what 's going on, and concerns are better
| separated.
|
| For example, the reverse proxy is no longer in the business of
| rewriting requests: there are other directives for that.
|
| In fact, we completely got rid of "rewrite hacks" that involved
| appending path components to the URI so they could be routed,
| then needing to strip those before proxying.
|
| Request matching is very powerful in Caddy 2: you can still
| easily match on paths in-line with your handler directives, but
| you can also match on any other part of the request (client IP,
| query string, regular expressions, etc) with an intuitive
| @-block syntax: https://caddyserver.com/docs/caddyfile/matchers
|
| Anyway, I think you'll feel right at home with it after a
| while. I've been using it for months now and it's _so simple_
| overall.
|
| (I also use the JSON config directly on a couple of my servers,
| where the behavior I need to express is way more elegant and
| concise than in the Caddyfile.)
| xrisk wrote:
| Thanks for the response! Looking forward to upgrade my stuff.
| Is there a reason why you decided to introduce an entirely
| new configuration method via JSON?
| mholt wrote:
| Yep, there are several reasons, you can read about them
| here:
| https://github.com/caddyserver/caddy/wiki/v2:-FAQ#why-
| json-f...
|
| Basically, it is highly interoperable and allows us to
| build config adapters on top of it, so you don't _have_ to
| use JSON if you really don 't want to. Most people use the
| Caddyfile. You can use YAML or TOML or CUE if you prefer
| those. Or heck, you can use your nginx config:
| https://github.com/caddyserver/nginx-adapter
| avolcano wrote:
| I liked v1 a whole lot. I'm interested in v2, though I'm
| extremely skeptical of the additional complexity of the config
| adapter layer (https://caddyserver.com/docs/config-adapters) -
| I'm more or less sold on having an internal JSON structure with a
| DSL on top of it (allowing dynamic/programatic config is really
| interesting), but the idea of having _multiple_ different DSLs or
| config syntax bindings for it seems a bit much.
|
| The biggest feature in Caddy 2, from what I can tell, is the new
| HTTP config API, and I'd love to see a practical example of what
| could be done with that.
| francislavoie wrote:
| Caddyfile is the primary supported DSL. The rest are nearly 1:1
| mappings to the internal JSON with some sugar, except for the
| nginx config adapter which is a bit special! For example jsonc
| provides JSON, but with comments.
|
| A few of those are third party maintained, and are plugins.
| They're listed on that page to point out what's possible.
|
| There's a tutorial for the API in the docs that should give you
| a good idea of what you can do:
| https://caddyserver.com/docs/api-tutorial
| mholt wrote:
| Don't worry about the "additional complexity" -- config
| adapters are modular, and only the Caddyfile adapter is baked
| into the standard modules. Just plug in the adapters you need.
| Caddy functionality can grow rather infinitely without bloat
| because of this.
|
| Some adapters are 1:1 translations so they are just a few lines
| of code:
| https://github.com/caddyserver/json5-adapter/blob/master/jso...
|
| True, the Caddyfile adapter is a bit of a beast because it is
| extensible itself -- but it's a _lot_ cleaner and more flexible
| than the v1 implementation, where the Caddyfile was its
| _native_ config syntax.
|
| Believe me, this is a big improvement.
|
| Anyway, you don't have to use the adapters if you don't want
| to. That's the beauty of it.
|
| More info on the architecture and config adapters:
|
| - https://caddyserver.com/docs/architecture
|
| - https://caddyserver.com/docs/config-adapters
| nikivi wrote:
| At what point does one use Caddy over writing a server with few
| lines in Go/Node. A bit confused on the use case of Caddy.
| tyingq wrote:
| I imagine it's quite a lot more than a few lines of code to
| correctly handle HEAD requests, ssl/tls, etags, expires
| headers, and so on.
| hairyhenderson wrote:
| Use Caddy wherever you'd otherwise use Apache HTTPD, nginx,
| IIS, traefik, Kong, etc...
| molszanski wrote:
| Why traefik? They both seem to be amazing modern web servers
| dubcanada wrote:
| It's comparable to Nginx and Apache, not a Go/Node http/https
| server.
| cthalupa wrote:
| I see Caddy as your general use case production web server
| prior to hitting large scaling needs. I've never gotten it to
| perform as leanly or scale as well as nginx, but most people
| will probably not need the headroom nginx provides vs. caddy.
|
| Caddy is significantly easier to manage and get running to a
| "good enough" stage for people that aren't familiar with nginx
| and apache, even for most medium sized production deployments.
|
| But, if you've got a team that's comfortable with nginx or
| apache, and doesn't find themselves spending an undue amount of
| time fiddling around with managing them, I don't personally
| believe there's any reason to switch from them to caddy.
| QUFB wrote:
| Caddy's TLS features are available in CertMagic
| (https://github.com/caddyserver/certmagic) for your daily
| Golang web app development. Highly recommended!
| zimbatm wrote:
| This is really a side-note. I think Caddy is great.
|
| > Still the only web server to use TLS automatically and by
| default.
|
| This sounds great at first. It also makes it too easy to hit the
| Let's encrypt rate-limit by mistake and get stuck for a week. I
| really think that the default should be to use the staging
| environment certs[1] instead and have the user actively decide
| when they are ready to go live.
|
| [1]: https://letsencrypt.org/docs/staging-environment/
| francislavoie wrote:
| Caddy v2 does this! If an ACME error is encountered, it will
| continue to retry via the staging endpoint instead until it
| works.
|
| This won't help if you're throwing away the data storage
| directory though (i.e. not persisting the volume with Docker),
| because Caddy won't have a way to keep track of what happened
| in past runs.
| mholt wrote:
| We thought of this! As francislavoie said, Caddy's retry logic
| involves switching to the Let's Encrypt staging endpoint until
| the DNS resolves properly. That is coupled with exponential
| backoff.
|
| Hitting the staging endpoint as a test isn't a perfect thing,
| by the way -- it can help where DNS records are misconfigured,
| but for things like rate limits or other state _internal to the
| CA server_ , switching endpoints will only give you a false
| positive.
|
| So, better to not hit that problem in the first place, and to
| make sure your DNS records are configured properly first.
|
| You can read more about these best practices here:
| https://docs.https.dev/acme-ops#avoid-using-a-production-ca-...
| renewiltord wrote:
| Is there a quickstart that just goes: do this to make a reverse
| proxy? i.e. you have a great manual, but I'm looking for a
| tutorial.
| francislavoie wrote:
| Yup!
|
| https://caddyserver.com/docs/quick-starts/reverse-proxy
| [deleted]
| m_sahaf wrote:
| There's a full tutorial on the Documentation section! Start
| here https://caddyserver.com/docs/getting-started and go
| through the links listed under "Tutorial" on the left side of
| the page.
| e12e wrote:
| I'm afraid I agree with a few sibling comments here, the
| documentation, although good, still feels a bit light for 2.0
| (I recently set up a caddy reverse proxy on a legacy host, in
| order to be able to avoid an old version of openssl - and
| decided to go with 2.0 - then in pre-release).
|
| That said, if your needs are simple, the examples are pretty
| good - a caddy file shouldn't have to be too many lines:
|
| https://caddyserver.com/docs/caddyfile/directives/reverse_pr...
|
| Ed: or see the quick-start section - linked in a sibling
| comment.
| mholt wrote:
| Yes, we do! Others have linked to it.
|
| Did you see the "Tutorials" section at the top of our docs,
| along with the quick-start guides, one of which is specifically
| for reverse proxying? https://caddyserver.com/docs/
| mxschmitt wrote:
| I really like Caddy and use it e.g. in Try Playwright:
| https://github.com/mxschmitt/try-playwright/blob/master/fron...
|
| For me as a user, the documentation is sometimes not very clear
| if it comes to Caddyfile syntax vs. JSON. It would be maybe
| better to always provide both or configurable via some switch
| e.g. (maybe its only for me not always fully clear).
|
| -> Great product, nice security settings by default and for me
| definitely the way to go.
| buttersbrian wrote:
| and does it currently work with python apps that work via wsgi?
| francislavoie wrote:
| There's no wsgi transport built-in, we haven't found any golang
| libraries that let us do this yet. For now, until we find a
| solution, we recommend using something like gunicorn and use
| the `reverse_proxy` directive in Caddy to proxy to it.
| benhoyt wrote:
| I recently switched my site from using Amazon Linux 1 + Apache +
| manual setup to Amazon Linux 2 + Caddy 2 + automated Ansible
| setup. The documentation for Caddy 2 wasn't quite 100% at the
| time, but it looks like it's in much better shape now. But Caddy
| 2 just worked, and gave me SSL seamlessly out of the box, zero
| config. Love it! My entire Caddyfile looks like this:
| giftyweddings.com { encode gzip reverse_proxy
| localhost:8080 # Go web server }
| www.giftyweddings.com { redir
| https://giftyweddings.com{uri} permanent }
|
| Also, mholt's "Caddy saves money" quip on the homepage was true
| in my case. After the switch I was able to downsize my instance
| to a very small size and save about 50% on my AWS bill, down to
| less than $10 per month. Not entirely sure it was due to Caddy,
| but I "blame" it on that anyway. :-)
| benhoyt wrote:
| The one thing I found tricky was getting the systemd config
| file correct (I'm not a Linux pro). Looks like he's addressed
| that too, with this README and demo systemd config -- nice!
| https://github.com/caddyserver/dist/tree/master/init
| mholt wrote:
| That systemd file was def. a community effort.
|
| Glad to hear Caddy is working for you!
| gfosco wrote:
| I really like Caddy and use it for general side projects. Super
| simple setup, handles all the LetsEncrypt certificates for me,
| can be running different apps on different paths.
| guillem_lefait wrote:
| Same here. Using it for all "small" projects, no idea on what
| to expect on large ones though.
| mholt wrote:
| We have several companies using it for tens of thousands of
| their customer sites. It's the only server we know of that
| can handle hundreds of thousands of certificates efficiently!
| rcarmo wrote:
| Looks great. I have fond memories of Caddy 1.x, but I keep
| looking for a reverse proxy that can do social auth to protect
| selected endpoints (I was betting on Traefik having an easy to
| setup extension for that, but 2.x has been a challenge in other
| ways...).
|
| Anyone know if Caddy 2 has any such extension beyond the basic
| auth provider I see in the docs?
| francislavoie wrote:
| Yep! greenpau has been doing a ton of work on authentication
| modules recently.
|
| See here for a list of some of the plugins we have available so
| far for Caddy v2: https://caddy.community/t/list-of-
| caddy-2-modules/7839
|
| A user has been working on an OAuth2 plugin recently:
| https://caddy.community/t/caddy2-redirect-from-within-caddya...
| danogentili wrote:
| I started using caddy v1 thanks to lightning-fast and simple TLS
| setup and extremely simple configuration in general, thanks to
| the excellent docs and handy plugins for common stuff like cors,
| rewrites and fastcgi.
|
| Shortly after upgrading to caddy v2, I switched to nginx, after
| spending way too much time trying to make sense of the new
| Caddyfile and docs (the thing I miss the most of the docs is the
| plugin list, along with the cors plugin, and in general the non-
| existant entry curve of Caddy v1). Tbh, I also miss the one-liner
| install script <3
|
| I'm genuinely sorry for the project; I didn't mind at all any of
| the previous so-called shady behavior (I personally don't object
| at all against a developer trying to make a living out of his own
| open-source project); I've been using caddy for four years now,
| and I really hope to switch back to it, one day.
|
| Thank you for your work, mholt! <3
| mholt wrote:
| As francislavoie said, the website with its nice one-click
| custom download page and list of registered plugins is a lot of
| work. It'll come, but it's not ready yet. Much like the v1
| release 5 years ago where the interactive download page didn't
| come until about a year later, it'll take some time. Hopefully
| not a full year though. :)
|
| I've already got the new build server mostly written -- should
| be way faster.
| coder543 wrote:
| Maybe this has changed since I looked at things yesterday,
| but I couldn't find a list of default plugins anywhere on the
| website, nor how to configure those default plugins. I think
| this is what the person you're replying to is talking about.
|
| On the old site, there was a plugin documentation page that
| made it trivial to see what the plugins were called and what
| options they took.
|
| I eventually asked my local copy of Caddy what plugins were
| available, which answered one of the two questions, but am I
| missing some kind of documentation page?
|
| The interactive, custom build page is an unrelated, but also
| interesting topic. About a year ago, I was using abiosoft's
| Caddy Builder image to build a Caddy docker image with the
| plugins I wanted, but this no longer seems to work even for
| Caddy V1, and I don't think it has been updated for V2. It
| would be awesome if there were an official Caddy Builder
| docker image. Even if the website existed, I would still have
| to wrap that binary in a docker image somehow for my own use
| cases.
|
| But, these are all just my personal opinions -- I'm sure you
| have your own priorities for the project, and I'm excited to
| see V2 has officially released!
| hairyhenderson wrote:
| > It would be awesome if there were an official Caddy
| Builder docker image
|
| You're in luck! :D
|
| https://hub.docker.com/_/caddy
|
| Note that the v2 images were _just_ pushed a few minutes
| ago, so the description might still point to rc3.
|
| See "Adding custom Caddy modules" on that page for
| instructions on how to use the `caddy:builder` image.
| mholt wrote:
| The new website does not yet have the ability to register
| plugins. I'm writing it -- I already have the new build
| server mostly written -- but like with v1, it may take a
| few months.
|
| It's not worth delaying the release for that, especially
| when we have tools like xcaddy that make it easy to build
| Caddy with plugins, no need to touch any code:
| https://github.com/caddyserver/xcaddy
|
| Right now, the process is: find a plugin you like, then
| run: xcaddy build --with <module-path>
|
| But yeah, it will get easier with time. We'll get there.
| m_sahaf wrote:
| The list of core plugins (now called modules) is here:
| https://caddyserver.com/docs/modules/
|
| If you're navigating from the homepage, click on
| "Documentation" at the top, then click on "modules" on the
| left navbar just above "JSON Config Structure". That list
| is generated directly from the source code, so it is the
| definite list of what's included by default and supported
| by the native JSON config.
|
| The other way is, as you found out, to run `caddy list-
| modules` to get the definitive list of what's packed into
| the binary.
| coder543 wrote:
| Thanks, this is what I was looking for!
| francislavoie wrote:
| If you need any help when coming back to Caddy v2, come ask for
| help on the community forums: https://caddy.community/
|
| We'll be glad to help you get set up!
|
| The docs are still a work in progress, we'll eventually have a
| plugin registry like in v1 but that requires a bunch of work
| behind the scenes to make it happen.
| nikisweeting wrote:
| YESSS so happy there's now an apt install method:
| echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" | sudo tee
| -a /etc/apt/sources.list.d/caddy-fury.list apt update &&
| apt install caddy
| francislavoie wrote:
| Yay!
|
| That was my pet project for the past couple weeks, I'm so glad
| to see people appreciate it!
| jbverschoor wrote:
| Yeah, not gonna use just any apt source. I'll pass.
| francislavoie wrote:
| You may already know this, but it's very tricky to package
| Golang projects in official debian repos because they require
| that every dependency be a separate package. This is a ton
| work both upfront and to maintain in the long-term, so we
| haven't made much progress on that front.
|
| We'd love to get some help from people who are more
| comfortable with the debian ecosystem though! It's definitely
| something we want to achieve, but for the short term we had
| to make the decision to simply release the .deb via
| https://gemfury.com which provides us with free APT repo
| hosting for open source projects.
| jbverschoor wrote:
| So you're saying that even if your app compiles to a single
| binary, that's a requirement?
|
| I understand why, but it's indeed quite a pain.
| francislavoie wrote:
| Yup. It's a bummer. https://go-
| team.pages.debian.net/packaging.html
| m_sahaf wrote:
| It's not a random source. The package is created by the
| release script in Caddy's repo: https://github.com/caddyserve
| r/caddy/blob/e051e119d1dff75972...
|
| There's ongoing effort to package Caddy into Debian. Until
| then, this is the alternative as stopgap.
| jbverschoor wrote:
| Nowhere on the website old or new is any info available.
|
| Thanks for pointing out
| jbverschoor wrote:
| I swear I couldn't find that page... been looking for
| half an hour.
| francislavoie wrote:
| It's the second link in the top-left of the docs sidebar!
| I'm surprised you found that difficult to find.
| m_sahaf wrote:
| It's mentioned on the "Install" page in the
| "Documentation" part of the website
| https://caddyserver.com/docs/install#debian-ubuntu-
| raspbian :)
| helij wrote:
| Is the license still the same. Pay for commercial user or compile
| on your own. Any change over the years?
| detaro wrote:
| Changed: https://github.com/caddyserver/caddy/issues/2786
| nodesocket wrote:
| Is there a tool that will parse a v1 config and report breaking
| changes and recommendations for upgrading to v2?
| mholt wrote:
| Nothing automated, but our upgrade guide will get you most of
| the way: https://caddyserver.com/docs/v2-upgrade
|
| Still, I recommend just going into v2 with a blank slate and
| just discover it anew. :)
| JackWritesCode wrote:
| Huge fan of Caddy. The on-demand TLS is incredible.
| mholt wrote:
| 5 years later and it still feels like magic.
|
| (Thank you, Let's Encrypt)
| bovermyer wrote:
| I just upgraded a server to Caddy 2 this past weekend. It's
| running a single WordPress site.
|
| There were some gotchas in converting the Caddyfile to the new
| format, but I eventually sorted it out. Caddy 2's method of
| updating the config made the iteration process a lot faster.
| mholt wrote:
| Thanks for sharing your experience!
|
| I'll admit I got bit by a few differences between the v1
| Caddyfile and the v2 Caddyfile too. Namely forgetting * at the
| end of a path _prefix_ matcher. (In Caddy 2, path matches are
| exact, unless you suffix with a *.)
| bovermyer wrote:
| How can I best share my config and learnings on this?
| m_sahaf wrote:
| The Caddy forum[0] would be one place! If you're writing a
| tutorial, protips, or anything like that, there's a Wiki
| category just for that.
|
| [0] https://caddy.community/
| nklmilojevic wrote:
| Hi @mholt, thanks a lot for Caddy. It is really awesome and we
| are considering using it for www.mailerlite.com landing pages.
| The problem that we have right now is that there is no Cloudflare
| plugin built-in for V2 so it is a show stopper for us.
|
| Congrats on the release!
| mholt wrote:
| Cloudflare plugin, that does what exactly?
|
| You mean like this one? https://github.com/caddy-dns/cloudflare
|
| (I'm using it today, works great. Assuming that's what you
| meant.)
| jlelse wrote:
| How to use this plugin with a Caddyfile?
| mholt wrote:
| tls { dns cloudflare <api_token> }
|
| Replace <api_token> with your API token, or you can store
| it in an env variable and use {env.CLOUDFLARE_API_TOKEN}
| for example.
| jlelse wrote:
| Thanks!
| nklmilojevic wrote:
| That's what I already tried and got:
|
| Error during parsing: getting DNS provider module named
| 'cloudflare': module not registered: tls.dns.cloudflare
|
| Using latest docker image.
| mholt wrote:
| "Latest", as in "1 hour ago" latest, or "15 minutes ago"
| latest? Because the 2.0 image (not RCs) is needed and I
| think it only got published a few minutes ago.
|
| Edit: You also need to plug it in.
| xcaddy build --with github.com/caddy-dns/cloudflare
| nklmilojevic wrote:
| I have just tried again, used caddy:latest and got the
| same error. Didn't mean to take much of your time, I can
| open up a GitHub issue if it's the better way to resolve
| this.
|
| EDIT: I have just seen your edit. Will try and report
| back.
|
| Thanks for your time!
| francislavoie wrote:
| Make sure to run "docker pull caddy"!
|
| Also, see the docs on docker hub:
| https://hub.docker.com/_/caddy/
|
| You'll need to build Caddy with the builder image to add
| the DNS plugin, see the section titled "Adding custom
| Caddy modules".
| nklmilojevic wrote:
| Yes, it works like this, thanks @mholt and @francislavoie
| for the help. I thought it was baked into caddy already.
| :-)
| madmax108 wrote:
| I know that HN is usually the first to outrage when a project
| website is too verbose or does not explain the product, but I
| just want to take a moment to say WHAT A GREAT WEBSITE Caddy has!
|
| - The first screen tells me everything I need to know about what
| Caddy is and why it stands out
|
| - Scroll down on how to setup (hattip to whoever did the angled
| asciinema embed. Looks so cool)
|
| - Every page worth of scroll is _exactly_ the right amount of
| information with links to dig deeper
|
| - The Upcoming features at the end is such a great touch as well.
|
| - All this in a UI which looks absolutely great!
|
| Excellent work guys and congratulations on the V2 launch! Been
| playing with Caddy quite a bit for personal projects, and been a
| very happy user. Will definitely be using v2 more! :)
| mholt wrote:
| D'aww, thank you!
|
| I was really nervous to post this on HN because HN has also
| been the source of great misery for me in the past, frankly.
| But I'm relieved at the overall positivity today. Maybe because
| it's Star Wars Day we're all in a good mood?
|
| I'm glad you like the landing page. Took me a couple weeks of
| trying and throwing designs away, then a few days of concerted
| effort, just standing in front of my text editor cranking out
| HTML and CSS best I could muster. The visual touches aren't
| perfect but I'm quite pleased.
|
| ... come to think of it, reading the criticism from HN on other
| projects made me hyper-aware of certain things, like explaining
| what the product actually does, and how to lay it out, and not
| mess with scrolling, etc etc. (But not the toxic comments, I
| skip those.)
| weaksauce wrote:
| the landing page almost looked _too_ slick and polished! i
| thought it was a for sale program instead of an open source
| one at first. neat tool... thanks for sharing it
| BilalBudhani wrote:
| I have been using Caddy v1 for more than a year now as a web
| server for some of my production sites. I'm really happy with the
| simplicity of it and especially out of the box SSL support with
| LetsEncrypt. I believe with v2 I will be moving more of my sites
| to Caddy. Thank you for all the hard work :)
| mholt wrote:
| Thank you for sharing your experience. Glad to hear it. Feel
| free to join our forums and be a part of the community!
| https://caddy.community - could always use more people with
| experience helping out. :)
| quaffapint wrote:
| I see a mention of using it as an ingress controller, but not
| much in the docs. Is there more details on this or is this better
| suited to run in a container as opposed to using nginx for that
| and leave the ingress to traefik/etc?
| francislavoie wrote:
| We have an ingress controller plugin here:
| https://github.com/caddyserver/ingress
|
| It's still very much a work-in-progress and could use help to
| complete.
| someguy101010 wrote:
| EDIT: No more Telemetry nvm
| mholt wrote:
| It's out. The server was shut down months ago and v2 doesn't
| have a telemetry client at all.
| someguy101010 wrote:
| Thanks for letting me know!
| seaghost wrote:
| Hi Matt,
|
| Thanks for the nice piece of software. I like Caddy a lot. I
| would like to better integration with docker in terms of
| automated exposure of docker services based on labels for
| example. Similar how traefik does. That would be really nice to
| have.
| mholt wrote:
| I've always felt like that was kind of a hack, but with Caddy's
| API it's doable. I don't really use Docker myself, so... want
| to contribute the feature? I'll show you how to integrate it.
|
| You might be interested in this discussion:
| https://github.com/lucaslorentz/caddy-docker-proxy/issues/13...
| interactivecode wrote:
| Soo who is building a UI for caddy servers?
| m_sahaf wrote:
| A wild UI was observed https://github.com/shynome/caddy2-ui !
| So it can probably be a community effort
| dilandau wrote:
| Since the author appears to be in the comments, I'll ask here:
|
| What benefits does this provide for the common Nginx usage
| (reverse proxy to a number of Python/etc application servers)? I
| see automatic HTTPS and HTTP/2. Am I missing something else
| notable?
| mholt wrote:
| It's written in Go, so right out the gate you get stronger
| memory safety guarantees than other servers written in C, which
| results in more secure software on your edge.
|
| Caddy's HTTPS/TLS implementation is among the most robust in
| the industry - powered by Go's performant and fairly
| bulletproof TLS stack, and combined with CertMagic's advanced
| TLS automation logic, your sites can stay online through
| situations that are problematic for other setups.
|
| Fewer moving parts means less that can go wrong. Caddy will
| make you more productive and lower your costs.
|
| An on-line config API is nice if you are automating anything.
|
| You might even be able to use your existing nginx config to
| begin your transition: https://github.com/caddyserver/nginx-
| adapter
| trillic wrote:
| Congrats on the launch Matt. I've been a long time Caddy user as
| a reverse_proxy for my home server. Using Caddy has been a
| wonderful experience.
|
| Thanks!
| sizeofchar wrote:
| I am a happy user of Caddy v1, and I want to thank you
| developers! It's made my life much easier, managing TLS
| automatically for my home server, and having a less than 10 lines
| adequate config for 3 web services I use behind it. I even forgot
| I was using Caddy, which is a proof of how great it is for
| systems integration.
|
| I'll be looking forward to v2 in a few weeks, when I will upgrade
| to newer ubuntu and go full ZFS.
|
| Thank you!
| mholt wrote:
| Love reading stuff like this, thank you.
| avip wrote:
| Started using Caddy because of OOTB ssl support which literally
| took 5m setup in container.
|
| Have been running Caddy in production for a year with no issues
| and much rejoice over my 3 loc config which I can literally
| memorize.
|
| All praise to Caddy's devs gj
| schoolornot wrote:
| I somewhat remember the Caddy team having a history of shady
| behavior: advertisements in headers, hostility towards
| contributors, telemetry you have to opt-out of. Has any of this
| changed or has it become worse?
| mholt wrote:
| The headers was one of the worst days of my life, believe me. I
| heard your feedback loud and clear and they were removed
| shortly thereafter... now about 3 years ago:
| https://caddy.community/t/the-realities-of-being-a-foss-main...
|
| The telemetry server was shut down months ago and v2 has no
| telemetry client. Although, the counts we gathered were
| informative. We learned a lot about MITM activity on the
| Internet, the health and maturity of TLS clients, and how many
| connections Caddy has secured (trillions, if you're wondering).
|
| As for whether things have gotten worse, I suppose that's up to
| you!
| petre wrote:
| Why did you do it? What have you sought to achieve with it?
| It's always a head scratcher for me why people building open
| source tools would put time and effort towards telemetry.
| Advertisments in HTTP headers? That's a new one. Advertise to
| whom, devs looking at a browser debug console?
| cthalupa wrote:
| >It's always a head scratcher for me why people building
| open source tools would put time and effort towards
| telemetry.
|
| Because you want to know what people are actually using in
| your projects. I've never put telemetry in anything I use,
| but I 100% understand why. It's hard to prioritize feature
| development if you don't know how people are using what
| you're making, especially if the users aren't very vocal.
| Without people talking to you and without telemetry on what
| people are doing, you might spend months worth of man-hours
| on something no one cares about.
|
| For projects where all you do is build out the things you
| specifically need this isn't an issue - all you care about
| is making the stuff you're doing work, and people getting
| benefit out of things is a bonus but not necessarily your
| goal. People will submit pull requests or feature requests,
| or they won't. No skin off your nose. Not all projects are
| developed this way, though.
| mholt wrote:
| It was for a class during my grad program. It was an
| academic interest in understanding client behavior on the
| Internet that wasn't limited to proprietary networks like
| Cloudflare or Google.
|
| We collected some good measurement data -- anonymous,
| technical, non-personal, etc -- but the terabytes added up
| and the academic community didn't seem particularly
| responsive to it in the end. The "opt-in" / "opt-out"
| depended on how you built/obtained Caddy, but essentially
| we made it a compile-time decision so that we could reduce
| biases from the data. By deciding on the download page
| whether telemetry was enabled, we could also know how
| representative the data actually was: otherwise it'd be
| meaningless.
|
| We also wanted to know how widely Caddy was being used.
| Telemetry was mostly just counts of things, so that's how
| we know that Caddy has secured trillions of HTTPS requests
| and managed millions of certs. But it was expensive to run.
|
| The "ads" in headers were _intended_ to be a friendly nod
| to our sponsors who made it possible. It was a novel idea.
| I thought it was a good balance of non-intrusive and
| perfectly visible at the same time: developers who were
| peering into HTTP requests would see the headers and our
| sponsors would get some benign recognition from their
| target audience, while nobody else would see them. It also
| was supposed to encourage purchasing commercial licenses,
| which didn 't have that header. The licenses were necessary
| to continue funding a desperately underfunded project.
|
| Needless to say that didn't work out and the only reason
| the Caddy project didn't shut down entirely is because
| corporate sponsors (Ardan Labs and one other to be
| announced probably next week) believed in the project
| enough to pick it up.
|
| So anyway, I also got college credit for implementing an
| Internet measurement system, which was really fun and
| interesting. And as mmalone said adjacently, open source
| projects _really_ need to know what kind of usage they 're
| getting. With no way to engage customers except at their
| voluntary discretion, it's impossible to know how to
| improve the project. Open source is, by definition, an open
| feedback loop. It only closes if users come back and
| provide information.
|
| A lot of other major open source projects or free software
| ship telemetry, even on by default sometimes -- see
| Windows, Chrome, Ubuntu, Firefox, VS Code, macOS, and
| countless others. Yet nobody cares.
|
| But having that information was critical in shaping the
| development of Caddy 2, FWIW.
| stonogo wrote:
| >Yet nobody cares.
|
| People care about each and every one of those. It's
| disingenuous to pretend that Caddy was singled out.
| francislavoie wrote:
| Look at the amount of vitriol Caddy got when it
| originally announced telemetry:
| https://news.ycombinator.com/item?id=16958674
|
| It's not a stretch to say that other projects didn't get
| as much hate for it. It really hurt the project's
| momentum when there was such a strong reaction against
| it.
| mmalone wrote:
| I wish there was a better way manage telemetry for open
| source. We have this problem at smallstep, too. We don't have
| any telemetry -- nothing is instrumented / nothing phones
| home -- but that means it's really hard to know which
| features are popular. Which makes it hard to prioritize. We
| only find out when something breaks and we can look at the
| volume of issues, heh.
|
| We ask people to let us know if / how they're using our
| stuff, but very few people do. It's a tough problem.
| hairyhenderson wrote:
| Matt's already spoken to the ads/telemetry (which are ancient
| history).
|
| My experience as a contributor has been nothing but positive.
| But if anyone's had a bad experience, I'm sure the Caddy team
| is more than willing to talk it out and reconcile.
| celicaraptor wrote:
| Hi mholt!, I am building an ecommerce SaaS.Obviously,i will have
| each domain pointed to my server.Is Caddy a good choice for
| automatically getting a certificate for each website?Are there
| any limitations? Thanks!
| mholt wrote:
| Yes, it is! Ask Jack Ellis at Fathom Analytics, they're doing
| this for their customers: https://usefathom.com/blog/bypass-
| adblockers -- and I think they have a new blog post and video
| coming out soon about it.
|
| Feel free to post in our forums with questions!
| https://caddy.community
| celicaraptor wrote:
| That's awesome to hear!I will be on the look out for their
| post.
| JackWritesCode wrote:
| We've had great fun with Caddy for Version 1 of our custom
| domains feature.
|
| For Version 2, we've done a lot of work with Matt and the
| solution we've now reached is:
|
| 1. DynamoDB as storage for certificates, allowing sharing
| between servers without regenerating during an issue with an
| availability zone
|
| 2. Multiple Caddy reverse proxy servers in different regions
|
| 3. AWS Global Accelerator to route the user to the closet
| server to them
|
| It's so great because we can also proxy our CDN through Caddy
| (yes, it needs to go through the user's custom domain), and
| we've got insanely fast response times on that.
|
| We've load tested the proxy servers and they can handle an
| incredible amount, we're very pleased with the solution.
|
| I will be publishing and sharing an article soon, detailing
| my journey and our final solution.
| going_to_800 wrote:
| Love this! I'm really REALLY interested in this post
| because I'm facing the same issue and TBH I'm not that
| great with servers myself.
| Mojah wrote:
| Hi!
|
| We've done this exact same thing and have a technical writeup
| here: https://ohdear.app/blog/how-we-used-caddy-and-laravels-
| subdo...
|
| Tl:dr: very easy to do, Caddy takes care of 90% of the
| complexity.
| celicaraptor wrote:
| Hi Mattias!, Thank you for pointing me your post.It really
| helped!Also,ohdear is a brilliant name for this service!
| mholt wrote:
| Hi HN -- this is what I've been working on for the last 14
| months, with the help of many contributors and the backing of
| several sponsors. (Thank You!)
|
| Caddy 2 is a fresh new server experience. Some things might take
| getting used to, like having _every_ site served over HTTPS
| unless you specify http:// explicitly in your config. But in
| general, it will feel familiar to v1 in a lot of ways. If you've
| used v1 before, I recommend going into v2 with a clean-slate
| using our Getting Started guide:
| https://caddyserver.com/docs/getting-started
|
| I'm excited to finally get this out there. Let me know what
| questions you have!
| pbreit wrote:
| What are some of the primary use cases you envision(ed) as well
| as any that have arisen?
| mholt wrote:
| It's often used as a reverse proxy and static file server,
| but oh, so much more is possible. Today, if you're using
| HTTPS, you should almost certainly be using Caddy. Maybe
| tomorrow if you need to set up a memory-safe SSH server, you
| could be using Caddy. (Just an example.)
| chris_st wrote:
| Sorry for the stupid question, but what is a "memory-safe
| SSH server"? Thanks!
| mholt wrote:
| Not a stupid question, it's not a phrase you hear very
| often because there isn't... really... one... at all.
| (Not in mainstream use AFAIK?)
|
| Memory safety is a class of guarantees certain software
| offers you against certain vulnerabilities. Software
| written in C is generally considered "memory unsafe"
| since it's hard to write correct C code when managing
| with memory, so it's easier to find exploits in them that
| cause them to reveal secrets.
|
| Go software has stronger memory safety guarantees than C
| programs like OpenSSH and Nginx. So that's one big
| benefit of using Caddy.
|
| As it happens, someone in the audience here is writing a
| SSH app for Caddy, so you have a pure Go SSH server that
| is less vulnerable to those class of attacks.
| atonse wrote:
| But what is the value add for Caddy here? Like how the
| out of box and auto SSL defaults with HTTP.
|
| Apart from memory safety, can the SSH version of caddy
| impose better defaults that OpenSSH doesn't right now?
| Maybe TLS certs, security key support, etc?
| [deleted]
| francislavoie wrote:
| To add onto what Matt said, here's a teaser:
| https://twitter.com/mholt6/status/1257073951525572608
| alexellisuk wrote:
| Congrats on the launch Matt. Great to see other independent
| software projects thriving like this. Keep up the hard work.
| gnalck wrote:
| Hey Matt - thanks for creating and maintaining Caddy all these
| years! Like others have said in this thread, it is so easy to
| set up and maintain that it really does feel like "magic".
|
| In terms of speeding up adoption of Caddy 2, it may be useful
| to have a list somewhere of the concrete improvements between
| the two (as I'm sure there are many). A (very) brief look and
| search around only yielded this article[1] which referenced
| another link of improvements that now 404s[2].
|
| Cheers,
|
| [1] https://caddyserver.com/v1/blog/caddy-2-ready-for-
| developers
|
| [2] https://github.com/caddyserver/caddy/tree/v2#list-of-
| improve...
| jbverschoor wrote:
| Adoption for me would be to have an official apt repo :)
| mholt wrote:
| I mean, we want one too, but it's ridiculously hard:
| https://news.ycombinator.com/item?id=23072385
|
| Help? :D
| mholt wrote:
| Thanks for the feedback! Glad you have had a good experience
| with it.
|
| That blog post is pretty old. We do have a current upgrade
| guide here in our docs:
| https://caddyserver.com/docs/v2-upgrade
|
| We also have a (sort of deprecated) wiki with some (slightly
| outdated) high-level improvements listed:
| https://github.com/caddyserver/caddy/wiki/v2:-Improvements
| x3haloed wrote:
| Another piece of feedback: It's scary to consider using
| such a crucial piece of software in production when
| documentation is referred to as "sort of deprecated" and
| "slightly outdated."
| francislavoie wrote:
| Because that's the old documentation, from early betas of
| Caddy v2.
|
| The official documentation at
| https://caddyserver.com/docs/ is up to date, and not
| deprecated.
| hoistbypetard wrote:
| Thank you for making this. Here's what I've been doing with it
| for the past month-and-change:
| https://geoff.tuxpup.com/posts/caddy_and_wireguard/
| mholt wrote:
| Very cool! I'll save this link.
| maxmunzel wrote:
| Thanks for the great work - caddy is a much needed breath of
| fresh air in the server space.
|
| One thing I stumbled upon the other day was that I (and google
| apparently, too) have trouble navigating the new website.
|
| I find it much simpler to find relevant information on the old
| site.
|
| Anyway, keep up the good work and stay healthy!
| mholt wrote:
| Thanks, we'll work on it! The nav/flow of content could
| probably be improved.
|
| Not gonna lie though, there's more to learn. V2 is a powerful
| machine -- so do expect that there will be some reading. Once
| you know how it works, it's easy to use. Very simple configs
| are possible, etc.
| mintplant wrote:
| Is there a list of those sponsors somewhere?
| mholt wrote:
| See the big "Thank you" note on the landing page; also GitHub
| sponsors: https://github.com/sponsors/mholt
| mrtweetyhack wrote:
| on the front page
| didip wrote:
| It is nice to see an alternative to Nginx. I am glad that Caddy
| took a stab at it.
|
| It is good that the author is looking to have some kind of stable
| monetization too. It's hard enough to maintain OSS from time
| perspective. I hope that it works out for him.
| wdavidw wrote:
| This new version looks amazing. I was actually looking at it
| earlier today. I had to postpone my upgrade because I couldn't
| find any alternative or how to include the http.git plugin which
| I rely on. Any direction in that regard will be appreciated.
| Congratulation for your work.
| francislavoie wrote:
| There's a git plugin for v2 here:
| https://github.com/vrongmeal/caddygit
| mholt wrote:
| Still WIP but very promising, and pure Go too!
| erikswn wrote:
| I just heared about Caddy v2 four days ago on a reddit post and
| it is awesome! Thanks a lot for your great work :)
|
| It is by far the easiest solution I could find to install a
| reverse proxy which can route by the URL /api/* and gets an
| automatic Let's Encrypt Certificate.
| mads wrote:
| I am using Caddy v2 in a Nomad cluster to serve static pages.
| Works great. Time to upgrade to the final v2. Thanks for a great
| piece of software.
| nhatcher wrote:
| I have been using Caddy for quite some time now, as a replacement
| for "python -m SimpleHTPServer" and by just flipping a switch as
| real webserver and this is such great news. I am so happy you end
| up going down the route of an open license, this right here is a
| game changer. I can't even begin to imagine the ins and outs that
| must have been crossing your mind in the last year. But, as
| things stands, I am very sure there is a bright future for Caddy.
| What a fantastic piece of software. I am one more to be grateful
| for this product. Thank you. You are helping people.
___________________________________________________________________
(page generated 2020-05-04 23:00 UTC)