Caddy Mac Run at Launch Error

I’m having trouble getting Caddy running at launch with a Mac OS X Launch Agent.

It loads when I run it in terminal with sudo without issues…can someone inspect my .plist file?

The error log when trying to run the load command shows this…which is puzzling me also, again, changing directory to cd /private/etc/caddy and running sudo caddy runs fine.


2019/06/18 17:09:12 registration error: acme: error: 429 :: POST :: :: urn:ietf:params:acme:error:rateLimited :: Error creating new account :: too many registrations for this IP: see, url:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">






Hi @robertgranholm, that’s LetsEncrypt telling you that they’ve rate limited your IP address because it keeps trying to make new accounts. It’s interesting that running Caddy manually has no problem. When you run it manually, does it serve any sites with Automatic HTTPS?

Unless you specify the environment CADDYPATH=/etc/ssl/caddy, when you run it with sudo caddy it will stash ACME assets in the /root/.caddy folder instead. So there might be an issue with the /etc/ssl/caddy directory. Although, the .plist has Caddy running as root:wheel, so it’d have to be something chronic (is the directory even there?).

Robert, I’m having trouble on mac, also. It all started for me last week or so… I forget now. Seems like it started right after I installed the 2019-003 high sierra security update.

You are getting the rate limits because caddy isn’t binding on the listen port but caddy keeps trying to renew.

I think my renewals had been failing for a while, but since the certificates were still valid, nothing was happening. but one of my domains was trying to renew with -1100 hours (that seems to me like it means that the cert expired 1100 hours ago. Since then, I moved the caddy working folder to a clean slate, and it fails ALPN for the first domain and the service fails.

I turned off “keep alive no matter what” so that I’d stop incurring a rate limit. I’ll try it again in the morning, but there is definitely something wonky happening on macOS with this.

Do you also run macserver?

See my thread here – Isn’t binding ports but not logging error either


Yes, automatic HTTPs is working when running it manually, which I have been doing while I can’t get this to work.

I seem to have a caddy folder in both locations you’e specified…is that an indicator of anything.

@jbmanos - not running server but I believe it started failing in the last 45 days or so…I just started running it manually and haven’t revisited until then.

Do you have homebrew letsencrypt installed?

I’m wondering if there’s a conflict with homebrew

Nope, not in my brew list, and I don’t recall installing it with homebrew

Ok. Did you have a letsencrypt install separate from caddy?

P.s. -1100 hours is 45 days. Roughly may 5, 2019. Both our machines stopped about the same time. That’s really odd.

It indicates a few things:

If /root/.caddy is present, and sudo caddy just starts up with no issues running the same Caddyfile as the service, it means you’ve used Caddy as root from the command line before, fetched all the necessary certificates, and there’s valid TLS assets in that folder.

Meanwhile, if the Caddy service is trying to register a new ACME account, it means that /etc/ssl/caddy doesn’t have valid TLS assets (at least, Caddy can’t find a valid ACME account there). The fact you’re rate limited implies the service has been repeatedly trying to rectify this.

I’m not sure why macOS is having issues with Caddy-as-a-service-as-root accessing /etc/ssl/caddy. But since you’ve got working assets in /root/.caddy you could edit your .plist to point CADDYPATH to the latter instead, as a workaround in th meantime.

That’s interesting because I set up a blank install with its own caddy root (/usr/local/var/run/caddyshack2/) so it would force caddy to “start fresh” ( after @matt suggested trying to delete locks ) - caddy still failed.

My certbot commands from the command line (renewing certs for the macserver webapps) worked fine. That runs from /etc/letsencrypt or something like that.

So the folder permissions in caddy’s folders are fine and caddy was able to make root:wheel owned folders inside

This is expected. LetsEncrypt has rate limited you. Until the rate limit expires, or you use a different ACME provider, they will not allow you to make any new account requests.

Probably because an ACME account already exists for it. The issue, I’d wager, is that Caddy isn’t preserving your ACME credentials between runs, so it needs to make a new account every time. This is the usual reason for being new-account rate limited by IP address.

Aye, that’s the weird part about this escapade. Root shouldn’t care what perms or ownership is set.

whaere should I look to see how many accounts had been made? My old caddy folder was /usr/local/var/run/caddyshack and since then I’ve made the duplicate “fresh” folder of the same name but with a 2 appended.

caddy would place the locks folders and all that jazz in there. If I new what I’m looking for in the files, then I could see if the theory is correct.

I hesitate to think that is the case, though, because caddy had been running continuously for 4 months before beginning of the errors

Oh, actually, I’ve gotten confused. Sorry, I thought I was responding to the OP, who had the error:

2019/06/18 17:09:12 registration error: acme: error: 429 :: POST :: :: urn:ietf:params:acme:error:rateLimited :: Error creating new account :: too many registrations for this IP: see, url:

Your issue is different.

1 Like

I apologize. I certainly didn’t mean to hijack @robertgranholm’s issue. I’m just surprised that he and I had a failure at about the same time. and on mac.

No worries about the confusions.

I don’t think I can actually use /root/.caddy though right?

is /~/.caddy acceptable? or do I need to actually do something like /Users/mediacenter/.caddy

1 Like

Well that didn’t work out well, now I have an error on running load.

mediacenterserver:caddy mediacenter$ sudo launchctl load -w /Library/LaunchDaemons/com.caddyserver.web.plist

/Library/LaunchDaemons/com.caddyserver.web.plist: Path had bad ownership/permissions

and lastly, a trip down educating myself on how to make edits in nano, you can ignore the previous comments, got it working!

Get this app. You’ll love it.

1 Like

No reason why you couldn’t use /root/.caddy. The reason I suggested it was because you’ve already got a working set of TLS assets there - it’s about using the existing, rather than the specific location.

Minor nitpick: You probably mean ~/.caddy, not /~/.caddy (very different locations).

Glad you got it working.

Second LaunchControl. It’s pretty handy sometimes.

What did you do to make it work?

At a guess… It was incorrect permissions on the .plist file after editing? MacOS gets pretty sensitive about that one.

1 Like