I use docker for the same reasons as the author's reservations - I combine a docker exec with some of my own loose automation around moving & chmod-ing files & directories to obviate the need for the acme client to have unfettered root access to my system.

Whether it's a local binary or a dockerised one, that access still needs to be marshalled either way & it can get complex facilitating that with a docker container. I haven't found it too bad but I'd really rather not need docker for on-demand automations.

I give plenty* of services root access to my system, most of which I haven't written myself & I certainly haven't audited their code line-by-line, but I agree with the author that you do get a sense from experience of the overall hygiene of a project & an ACME client has yet to give me good vibes.

* within reason

▲ paul_h a day ago | parent [-]

Copilot suggests:

    docker run --rm \
      -v /srv/mywebsite/certs:/acme.sh/certs \
      -v /srv/mywebsite/public/.well-known/acme- 
      challenge:/acme-challenge \
      neilpang/acme.sh --issue \
      --webroot /acme-challenge \
      -d yourdomain.com \
      --cert-file /acme.sh/certs/cert.pem \
      --key-file /acme.sh/certs/key.pem \
      --fullchain-file /acme.sh/certs/fullchain.pem

I don't know why it's suggesting `neilpang` though, as he no longer has a fork.

	▲	lucideer a day ago \| parent [-]
		Yeah I'm not running anything llms spit at me in a security-sensitive context. That example is not so bad - you've already pointed out the main obvious supply-chain attack vector in referencing a random ephemeral fork, but otherwise it's certonly (presumably neil's default) so it's the simplest case. Many clients have more... intrusive defaults that prioritise first-run cert onboarding which is opening more surface area for write error.