6 ms·

At this point I'd rather be good at Caddyfile and have a project folder of: /home/me/project/caddy /home/me/project/Caddyfile No sudo, no config spew acro

• kaptainscarlet 2y ago
  Caddy sounds like the go to tool for people who care a lot about getting things done. It's time for me to try it.
  • bavell 2y ago
    Eh, it's a bit over hyped imo although I do like the config format and built-in acme. My production clusters all run nginx though and give me minimal fuss with a lot of flexibility.
  • diarrhea 2y ago
    A coworker of mine dislikes it as it bundles everything into a single binary. For example, to have ACME DNS-01 challenges for certificate issuance working, I need to compile in a Google DNS-specific plugin. But then it... just works. Try the same with most other web servers/proxies and you're in for a world of pain. Having this much functionality bundled into a single binary is as much a curse as it is a blessing. That said, having your own little 'Cloudflare Workers' in the form of Nginx Unit with wasm sounds great. Not sure Caddy can do that.
    • TheCapeGreek 2y ago
      For me, the promise of Caddy and especially tools around it like FrankenPHP make the "everything in a single binary" idea the MORE enticing option, not less. Sure we already have repeatable infrastructure, containers, etc. but I also love the idea of just building and shipping a PHP app binary that includes the webserver. It makes server provisioning even less of a priority, especially if I have reasons to not use serverless or PaaS tools.
    • AbraKdabra 2y ago
      Having a single binary is definitely what drives me to use certain software, Deno is one of them.
      • beeboobaa3 2y ago
        It's great until you want to include a non-standard plugin and need to compile your own binaries. Now that single binary deployment requires you to compile the software yourself. Caddy has nice tooling for this but it'd be far more convenient to just drop a dll/so file in the right directory. Single binary deployments are great if someone else did the compiling for you. If you need to compile yourself it truly does not matter if you need to ship a single binary or a directory or whatever.
  • 9dev 2y ago
    If you want to see a real-life example of what Caddy can do, feel free to check the configuration of my iss-metrics project: https://github.com/Radiergummi/iss-metrics/blob/main/caddy/Caddyfile https://github.com/Radiergummi/iss-metrics/blob/main/caddy/C... I was in the same boat as you and wanted to try out what Caddy is capable of. I was immediately convinced. So many features, where you expect them. Consistent configuration language. Environment interpolation, everywhere. Flexible API. It’s really all there.
    • ac130kz 2y ago
      From the first glance it doesn't look convincingly better than a generic and manually polished nginx configuration. Are there any other benefits to Caddy?
      • corobo 2y ago
        It does all the letsencrypt stuff for you - certbot is not a massive hassle if you're just serving the one domain of course but I really liked it for that when I was setting up a redirect server (corps do love buying TheirBrand.everytld haha) Set the config up with CI/CD and can now just edit the config and git push knowing Caddy will just handle the rest
        • ac130kz 2y ago
          Seems to be a middleground between doing certs on a small scale with cronjobs and a fully fledged automated Kubernetes cluster.
          • nyolfen 2y ago
            it is a total displacement for the former and stupidly simple compared to the either; gold standard 'just works'
      • 9dev 2y ago
        If you choose to start the project with docker compose, you’ll notice how it will immediately bring up a fully functional reverse proxy setup with TLS support on localhost; set the SITE_DOMAIN environment variable to your proper domain instead, and you’ll find that configured as well, along with a proper, ACME-issued certificate. Add a bit more effort, and you’ll also get mTLS for all services automatically. All of this is more or less doable with nginx, I’ve done it often enough. But read the Caddyfile and tell me this isn’t miles ahead in clarity.
  • page_fault 2y ago
    It's a fine project right up to the point of you needing additional functionality that's split into one of the plugins. Since Go applications do not support proper .so in practice, you have to build your own binaries or rely on their build service, and this puts the responsibility of supporting and updating such custom configuration on you. So no setting up unattended-upgrades and forgetting about it.
    • thegeekpirate 2y ago
      I think that's what https://caddyserver.com/docs/command-line#caddy-upgrade https://caddyserver.com/docs/command-line#caddy-upgrade (and the following commands) are for ;)
      • beeboobaa3 2y ago
        > experimental also totally non-standard, apt unattended-upgrades won't be doing that for you. sure you can do a cronjob, but, non-standard
  • NetOpWibby 2y ago
    I recently setup a Flarum forum and the instructions mentioned Apache and Nginx. I sighed until I saw Caddy immediately below. Caddy really is the most pleasant webserver software I’ve ever used.
• _cenw 2y ago
  has anyone figured out why caddy is substantially slower (thoughput, not latency) than nginx at reverse proxying? i've switched it around for my seafile and it's a night and day difference.
  • ac130kz 2y ago
    Garbage collection pauses might have something to do with that.
    • dboreham 2y ago
      Unlikely.
    • tempest_ 2y ago
      Also the lack of 20 years of optimization where it spent a lot of time as one of the larger open source web servers and so got a lot of attention. In 2024 people are more likely to turn the cloud knob up to pay for throughput (if they need it) and save on dev time with the comparably better dev ex that caddy offers.
      • nickjj 2y ago
        > In 2024 people are more likely to turn the cloud knob up to pay for throughput (if they need it) and save on dev time with the comparably better dev ex that caddy offers. This seems like a weird trade off to me. The "learning tax" is really only paid once with nginx. Once you understand how it works and configured a reasonably end-to-end example with it then you can carry that over to your next project with minimal changes. I've hosted countless Flask, Django, Rails, etc. apps over the years and very little changes on the nginx side of things. I'd rather learn this tool once and have better runtime performance all the time across all projects. With that said, the performance difference probably won't be very noticeable for most sites but still, I personally wouldn't want to give in to running a less efficient solution when I know a more efficient solution exists right around corner that requires no application code changes to use -- just a little elbow grease to configure nginx once. This is especially true when nginx has a ~20 year track record of stability and efficiency.
• deleted 2y ago
  [deleted]
• cpach 2y ago
  AFAIK, nginx doesn’t require root. If you’re thinking about the ability to bind port 80/443, you should be able to do that via CAP_NET_BIND_SERVICE. With that said, Caddy is pretty rad.
• klabb3 2y ago
  This is more of a linuxism no? I agree though, I have used Linux for decades but I never remember the usr, bin, local, etc permutations of magical paths, nor do I think it makes any sense. It’s a mess honestly, and is almost never what I want. When I was younger I thought I was holding it wrong but these days I’m sure it will never, ever map well to my mental model. It feels like a lot of distro-specific trivia that’s leaking all over the floor. It seems like a lot of the hipster tooling dropped those things from the past and honestly it’s so much nicer to have things contained in a single file/dir or at most two. That may be a big reason why kids these days prefer them, honestly. As for nginx itself it’s actually much better suited for high performance proxies with many conns, imo. I ran some benchmarks and the Go variants (traefik, caddy) eat a lot of memory per conn. Some of that’s unavoidable because of minimum per-goroutine stacks. Now I’m sure they’re better in many ways but I was very impressed with nginxs footprint.
  • gjvc 2y ago
    honestly
    • klabb3 2y ago
      Making me self conscious, honestly. I’m not a patient and careful writer. That’s why I’m lurking in the comments.
  • nevermore24 2y ago
    I don't know if not being able to remember filesystem conventions is Linux's fault. Computers have a lot of esoterica and random facts to recall. How is this one any different? See also: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
  • kbenson 2y ago
    Windows has the same thing, it's just much less exposed, and none of the paths are magical, they're well defined and mostly adhered to for all major distros. The core of how it works in Linux is fairly straightforward. The main difference is in how additional software is handled. Windows, because of its history with mostly third party software being installed, generally installed applications into a folder and that folder contained the application... Mostly. Uninstalling was never as simple as that might imply. Linux distros had an existing filesystem layout (from Unix) to conform to, so when they started developing package managers, they had to support files all over the place, so they make sure packages include manifests. Want to know where use executable are? Check bin. Superuser.com executables? Check sbin (don't want those cluttering the available utils in the path of regular users). Libs for in libs. /bin and /usr/bin and the others are holdovers from the long past when disks were small, and recent distros often symlink usr to / so they're different in name only. /usr/local is for admin local modifications that are not handled through a package. /opt is for whatever, and often used for software installed into a contained folder, like in windows. Just know what bin, sbin, lib, opt and etc are for and most the rest is irrelevant as long as you know how to query the package manager for what files a package provides or as it what package a specific filer belongs to. If you looked I to windows and the various places it puts things I suspect you'd find it at least complicated, if not much more. Note: what I said may not match the LSB (which someone else usefully posted) perfectly, but for the most part it should work as a simple primer.
• renewiltord 2y ago
  These are things for sure, but nginx config files are well understood by LLMs so I get good advice from them. That's really the limiting factor for most equivalent tools for me these days, how well the LLM handles it. If someone hooks them up to a man page I think it might level the playing field.
• sofixa 2y ago
  I'm really not a fan of Caddy. It tries to be too smart and make things simple for users, which means that the second something goes wrong or you step out of the expected box, you get weird behaviour which is hard to debug. Fun example from last week, a colleague was trying to try out ACME with a custom ACME server, and configured it. For some reason Caddy was not using it and instead used its own internal cert issuer, even if explicitly told to use the ACME provider as configured. Turns out that if you use the .local domain, Caddy will insist on using its own cert issuer even if there's an ACME provider configured. Does that make sense? Yeah, somewhat, but it's the kind of weird implicit behaviour that makes me mistrust it. My go-tos are nginx for static stuff, Traefik for dynamic stuff.
  • vgb2k18 2y ago
    I bought into Caddy last year for its simplicity. Loved it, from the moment I saw the off-horizontal default page. I switched back to nginx last month because, like you said, I stepped outside of the expected box. Skill issue? Maybe... I transferred my gunvicorn webapp from WAN to LAN. No more dotcom, just 10.x.x.x ip. To say Caddy didn't like it: error messages were non-specific. Community knowledge (ie, stack overflow etc) was lacking. Then nginx.. It worked perfect with almost default config. Skill-issue or Caddy issue, the point is: Caddy is simpler sometimes.
  • mholt 2y ago
    What was the config? It should never override explicit configuration...
• gnaman 2y ago
  Unfortunately, Caddy does not support and do not plan on supporting anything other than HTTP/HTTPS. These days I find myself going back to nginx only for TCP/UDP reverse proxy.
  • m_sahaf 2y ago
    It supports it with the caddy-l4 plugin: https://github.com/mholt/caddy-l4 https://github.com/mholt/caddy-l4. It was also indicated we might move the plugin into standard Caddy once given enough feedback from the user-base and are comfortable with the implementation solidity.
• gedw99 2y ago
  I also prefer caddy with wazero plugin to run WASM . So easy and works on everything