Those "brittle" dynamically linked binaries work perfectly fine on my Gentoo system, thank you very much.
46 MB is not much though. Shouldn't even be a problem to run it on a RPi for example.
And of course I know the difference between actually used memory and memory used as buffers/cache...
Luckily the "MEM%" column in htop shows the resident memory of the process. One shouldn't look at the virtual memory column indeed.
Hm, Caddy doesn't seem to be packaged on my Rasbian (Bullseye) 
Yeah -- Caddy and Traefik and other Go programs are frequently run on low-end systems like Raspberry Pi.
Still, more a fan of Rust than Go personally 
Also memory safe! Unfortunately not a Caddy "clone" written in Rust as far as I can tell 
I would rather use Modula-2
No?
That seems to be using a third party repository. So no, it's currently not packaged on my Raspbian.
It's going to be packaged starting with bookworm: Debian -- Details of package caddy in bookworm
Raspbian stable is currently still on bullseye, so not there at the moment.
If that's the package I think it is, that's more like a fork. They've modified the Caddy source to remove features/functionality. It's also still on 2.6.2? It's not updated actively enough for us to recommend it. Best to stick to our official distribution I think.
Anyway, this thread might be getting derailed.
I'm happy to discuss Caddy packaging/nuances more maybe in a separate thread or on our own forums if you have questions/interest!
Personally I'm really interested in seeing how we can upgrade Let's Encrypt's position from recommending a single ACME client to helping users get on HTTPS the easiest, most reliable way for them.
I think we should not try to influence initial decisions about design nor implementation.
IMHO, we are here to help support such decisions.
Making recommendations for Caddy/Traefik leans more towards a [re]design process.
Question #1 should always be: What do you want to secure?
Question #2+ then goes towards the how and what you already have/prefer to use
For the very few that have nothing nor prefer anything [i.e. know nothing], they should work backwards from Q1 - the end product should be the one to provide them guidance on how they prefer to be secured [not us].
You have to do things securely AND you have to secure things this way!
I'm not good with that logic.
By the way, at EFF we went through a process a few years ago to attempt to do something like this for the Certbot landing page. There is no circumstance in which it recommends a client other than Certbot, but it attempts to show people the possibility that their hosting provider will already have an integration or perhaps that they should ask for one or consider switching, and that Certbot is relevant to them if they are the system administrators. This is the behavior that @bmw mentioned at the beginning of this thread:
This was a big effort to broadly help people understand whether Certbot is relevant to them or not. (One big case that this still tends to miss is, for example, people who could benefit from CertSageālike those who have a cPanel interface on shared hosting with the ability to install certs.)
I'm not sure whether one could get community consensus about specific recommendations, but it does seem like one could imagine a wizard/survey/document that somehow tries to explain...
This just emphasizes my previous point: any project/admin that could pull this off isn't your average (or above average) website infrastructure/developer. It's just not "accessible" for the average (or above average) case.
This is a really big use case that I think needs a lot of attention from somebody, though maybe not Let's Encrypt/Certbot. I feel like a lot of lost people posting here aren't really trying to run "a web site" at all, but use some kind of appliance on their own home network. But because "web browser" has become the universal UI for everything, they need to find a name and get a certificate, even if all they're trying to do is use it from within their own house and don't care about an externally-visible name or endpoint or anything. Sometimes these devices manage to provision themselves and it "just works", but when it doesn't it gets really hard for the user to understand what went wrong and how to fix it.
well, isn't any programming without manual memory management by definition "memory safe"? unless machine knows there is no pointer to it GC will keep that memory reserved.
Veering off topic but I believe the main difference with rust is you can know you're not memory safe at compile time, whereas Go prevents memory safety faults at run time with automated bounds checking. Runtimes like dotnet/C# and Java are also memory safe (within the scope of their runtime also being correct) and where they allow "unsafe" memory access it's still got bounds checking, it's only unsafe in the sense that the app might exit with an exception. All languages with C bindings (which is practically all of them) can be made genuinely unsafe by simply calling out to a C library that's broken.
My 5 cents have no problem with commercial offerings being recommended. Probably shouldnāt be the only recommended option though. Caddy is a great bit of kit and I use it for lots of things locally. More pressure on larger players to make tls first party citizens is great.
That said, I pretty much only use nginx on my own public facing stuff. More battle testing for alternative web servers is also great. Network effect of higher usage would give people more confidence in using Caddy, too.
Am not a fan of how removed Caddy is from the actual heavy lifting done by the go standard libraries. The syntactic sugar on top of this though and the support is great, but by being removed from the actual server code means being removed from decision making and really the ability to fix things quickly when necessary.
I see a lot of value in promoting applications to directly integrate first party acme support and removing a lot of the need for things like certbot at all.
I've been trying to fight this idea that "Caddy isn't battle-tested" for years now. It's used by governments, enterprises, non-profits, mission critical humanitarian services, hospitals, and it's older than / about the same age as Kubernetes. And most of the "heavy lifting" is done by Go and its standard library, which everyone will agree is battle-tested! If it's good enough for Google, Netflix, and Cloudflare, it's good enough for you too 
(And I think this ongoing stigma against new web servers like Caddy and Traefik which are memory-safe because they aren't "battle tested" -- which isn't true -- is hindering the adoption of safer infrastructure.)
I'm not really sure I follow this particular logic (feel free to take this to another thread or forum to discuss ), but I just want to let you know that we seem to share a lot of values based on the rest of your post, and I'm glad to see others who also want to see ACME integrated natively into web applications and servers. 
As a maintainer of lego and as a member of the open-source community around ACME and Let's Encrypt, I feel really uncomfortable about this topic.
I think that some other maintainers of ACME clients could feel the same thing.
Caddy is neither an ACME client nor the only open-source product (reverse-proxy, webserver, certificates manager) around the ACME topic.
There are a lot of ACME clients, written in different languages, and it's the same thing about products that handle ACME.
I always promoted Let's Encrypt over other ACME servers because I trust EFF more than a commercial company.
I understand the interrogation around Certbot but I feel really uncomfortable with this situation.
Note: I was an employee of the company that owns Traefik but I always worked on lego in my spare time.
I agree with you @elDez. And I am -- we are all -- thankful for your contribution to the community and ecosystem.
While I think Caddy is a good example, it sounds like the consensus so far is to educate and guide users into the right solution for them. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.