caddyserver/caddy · error
provisioning default public automation policy: %v
Error message
provisioning default public automation policy: %v
What it means
Caddy always creates an implicit default public automation policy (used for any names not matched by explicit policies) and provisions it via AutomationPolicy.Provision. This error means that implicit policy failed — most commonly the default issuers (ACME/ZeroSSL) could not be provisioned, e.g. missing ACME account email, or a default storage/issuer construction error inside automation.go.
Source
Thrown at modules/caddytls/tls.go:296
if t.Automation != nil && t.Automation.OnDemand != nil && t.Automation.OnDemand.PermissionRaw != nil {
if t.Automation.OnDemand.Ask != "" {
return fmt.Errorf("on-demand TLS config conflict: both 'ask' endpoint and a 'permission' module are specified; 'ask' is deprecated, so use only the permission module")
}
val, err := ctx.LoadModule(t.Automation.OnDemand, "PermissionRaw")
if err != nil {
return fmt.Errorf("loading on-demand TLS permission module: %v", err)
}
t.Automation.OnDemand.permission = val.(OnDemandPermission)
}
// automation/management policies
if t.Automation == nil {
t.Automation = new(AutomationConfig)
}
t.Automation.defaultPublicAutomationPolicy = new(AutomationPolicy)
err = t.Automation.defaultPublicAutomationPolicy.Provision(t)
if err != nil {
return fmt.Errorf("provisioning default public automation policy: %v", err)
}
for n := range t.automateNames {
// if any names specified by the "automate" loader do not qualify for a public
// certificate, we should initialize a default internal automation policy
// (but we don't want to do this unnecessarily, since it may prompt for password!)
if certmagic.SubjectQualifiesForPublicCert(n) {
continue
}
t.Automation.defaultInternalAutomationPolicy = &AutomationPolicy{
IssuersRaw: []json.RawMessage{json.RawMessage(`{"module":"internal"}`)},
}
err = t.Automation.defaultInternalAutomationPolicy.Provision(t)
if err != nil {
return fmt.Errorf("provisioning default internal automation policy: %v", err)
}
break
}
for i, ap := range t.Automation.Policies {View on GitHub (pinned to 50e54ee279)
Solutions
- Read the wrapped error text — it originates in AutomationPolicy.Provision and names the sub-step (issuers, storage, certmagic config)
- Simplify: remove global tls customizations (acme_ca, email, storage) and re-add one at a time to isolate
- Ensure any storage plugin configured at the app level loads correctly
- Check that you are not disabling both default issuers without providing replacements in automation.policies
Defensive patterns
Strategy: try-catch
Prevention
- Keep global tls settings minimal and test each addition (acme_ca, email, storage) with 'caddy validate'
- The wrapped error is always the real diagnosis — read it before changing config
When it happens
Trigger: DefaultIssuersProvisioned failing — e.g. explicitly disabled ACME issuer combined with an email requirement, or errors building certmagic config for defaults; also fails if global storage is misconfigured since the default policy inherits app storage. Because the policy is synthesized (empty AutomationPolicy), user-triggerable causes are indirect: global tls settings like 'acme_ca', 'email', or storage modules.
Common situations: Custom global issuer settings (e.g. acme_ca pointing to a bad URL shape), storage plugin failures, or experimental Caddy builds where default issuer wiring changed; frequently the wrapped error pinpoints the real cause in automation.go.
Related errors
- provisioning automation policy %d: %v
- finalizing automatic HTTPS: %v
- provisioning default issuer %d: %T: %v
- loading overall DNS provider module: %v
- provisioning default internal automation policy: %v
AI-assisted analysis of caddyserver/caddy@50e54ee279 (2026-08-15).
Data as JSON: /api/errors/cdac7839f436483b.
Report an issue: GitHub.