Hook for renewal a bunch of certificates using acme.sh

I have several certificates that are stored in a git repository. I would like to setup an auto-renewal of these certificates and automatically push them to the repo every 60 days. I issue my certificates like this:

for domain in $DOMAINS; do
  ./acme.sh --server letsencrypt --dns dns_cf --home $PROJECT_NAME --issue -d $domain -k ec-256 --preferred-chain "ISRG Root X1" --renew-hook /path/to/hook

  ./acme.sh --ecc --install-cert --home $PROJECT_NAME -d $domain --key-file /path/to/key-file --fullchain-file /path/to/fullchain-file

This is the cronjob that I use for the renewal.

0 0 * * * "$HOME/.acme.sh"/acme.sh --cron --home "$HOME/.acme.sh/$PROJECT_NAME" > /dev/null

Here I managed to find the description of a renew-hook that states that it is called when certs are successfully renewed. But the problem I've encountered is that the renew-hook is called for every certificate, which is not very convenient for me because I would like to wait until all the certs are renewed and then make a single commit.

I, of course, can write a separate script that's not connected to acme and push the certificates to the repo without any acme hooks using cron, but it won't look nice and I think it's ideologically wrong.

I couldn't google a standard solution for this problem, could anyone please tell me what's the best way to do this?

Ideologically I'd consider pushing each cert to an actual secrets vault instead (Hashicorp vault, Azure Key Vault etc), then on the side of your consumer (webservers etc) doing a regular pull from the secrets vault.

The task of only pushing to git when all your certs are renewed would require a custom script that you would also have to maintain as you added more certs, it would simply go through they list and check they were all recently modified, then push. Note that if one renewal failed it would hold back the commit for all the certs.

You could alternatively push each cert upon renewal to a branch, then squash and merge that branch when your criteria has been met. It doesn't really smell like the right strategy overall though because it creates and artificial interdependency between the certs, and because certs (or more specifically private keys) generally shouldn't be committed to a source code repo.