caddyserver/caddy · error

automate: manage %v: %v

Error message

automate: manage %v: %v

What it means

Inside TLS.Manage, names are grouped by automation policy and each group is managed asynchronously via ap.magic.ManageAsync. If asynchronous management of a batch fails (challenge failures, issuer errors, context cancellation during shutdown), that error is wrapped here; for readability only the first 100 names are listed with '(and N more...)'.

Source

Thrown at modules/caddytls/tls.go:592

		if t.managingWildcardFor(subj, subjects) {
			if _, ok := t.automateNames[subj]; !ok {
				continue
			}
		}
		policyToNames[ap] = append(policyToNames[ap], subj)
	}

	// now that names are grouped by policy, we can simply make one
	// certmagic.Config for each (potentially large) group of names
	// and call ManageAsync just once for the whole batch
	for ap, names := range policyToNames {
		err := ap.magic.ManageAsync(t.ctx.Context, names)
		if err != nil {
			const maxNamesToDisplay = 100
			if len(names) > maxNamesToDisplay {
				names = append(names[:maxNamesToDisplay], fmt.Sprintf("(and %d more...)", len(names)-maxNamesToDisplay))
			}
			return fmt.Errorf("automate: manage %v: %v", names, err)
		}
		for _, name := range names {
			// certs that are issued solely by our internal issuer are a little bit of
			// a special case: if you have an initial config that manages example.com
			// using internal CA, then after testing it you switch to a production CA,
			// you wouldn't want to keep using the same self-signed cert, obviously;
			// so we differentiate these by associating the subject with its issuer key;
			// we do this because CertMagic has no notion of "InternalIssuer" like we
			// do, so we have to do this logic ourselves
			var issuerKey string
			if len(ap.Issuers) == 1 {
				if intIss, ok := ap.Issuers[0].(*InternalIssuer); ok && intIss != nil {
					issuerKey = intIss.IssuerKey()
				}
			}
			t.managing[name] = issuerKey
		}
	}

View on GitHub (pinned to 50e54ee279)

Solutions

1. Inspect the wrapped certmagic error for per-domain cause (challenge type, rate limit URLs, DNS errors)
2. Fix the specific failing domain's reachability/DNS, or move it to its own policy with the internal issuer if it is not publicly valid
3. Retry after transient network issues — issuance is retried with backoff while Caddy runs; consider 'caddy reload' to retrigger
4. Use staging CA during bulk testing to avoid production rate limits

When it happens

Trigger: A batch of subjects under one policy where one or more fail issuance/renewal: unreachable HTTP challenge port, DNS propagation timeout, rate-limited ACME account, expired DNS provider credentials. Can also surface at config reload when renewals are re-checked for all managed names.

Common situations: Bulk-managing many domains where a single failing domain aborts the group's report; renewals breaking after credentials rotate; transient network failure at startup; context cancelled by an immediate subsequent config change.

Related errors

• finalizing automatic HTTPS: %v
• provisioning default public automation policy: %v
• automate: managing %v: %v
• consolidating TLS connection policies for server %d: %v
• server listening on %v is HTTP, but attempts to configure TL

AI-assisted analysis of caddyserver/caddy@50e54ee279 (2026-08-15). Data as JSON: /api/errors/045eadbd7cadd397. Report an issue: GitHub.