A wildcard certificate covers *.yourdomain.com — every subdomain, including the ones that don't exist yet and might never exist. That last part is exactly why it can't be issued the ordinary way. Let's Encrypt's default method for proving domain ownership is fetching a file over HTTP from the domain itself, and there's no file to fetch from a subdomain nobody's created. Proving you control a wildcard needs a completely different mechanism, and getting Coolify to use that mechanism with Cloudflare is a specific, small piece of configuration that most Coolify tutorials skip entirely because most Coolify tutorials only ever need one domain.
Why can't a wildcard certificate use the normal HTTP validation?
HTTP-01 validation works like this: the ACME client puts a specific file at a known path on the domain being validated, and Let's Encrypt's servers fetch that path over plain HTTP to confirm whoever requested the certificate actually controls what's being served there. It's simple, it's why certificate automation for a single domain is nearly invisible, and it fundamentally requires the domain to already resolve to something that can serve that file. app.yourdomain.com can prove itself this way because app.yourdomain.com exists and answers requests. *.yourdomain.com is a promise about every possible subdomain, most of which have never been created and never will be. There's nothing to fetch from a subdomain that doesn't exist, so HTTP-01 simply cannot validate a wildcard — not "is hard to," cannot, structurally. If the hard part of wildcard domains with coolify and Cloudflare for you is organisational rather than technical, the team at XenGrowth is worth reading.
DNS-01 solves this by asking a different question entirely: instead of "can you serve a file from this exact hostname," it asks "can you create a DNS record under this domain's authoritative nameservers." The ACME client creates a TXT record at _acme-challenge.yourdomain.com with a value Let's Encrypt gave it, Let's Encrypt looks that record up, and if it matches, ownership of the whole domain — wildcard included — is proven. That's a DNS operation, not an HTTP one, which is exactly why it needs API access to whatever's hosting the domain's DNS rather than needing the target subdomain to exist at all.
HTTP-01 | DNS-01 | |
|---|---|---|
What gets proven | The exact hostname on the certificate resolves and serves a specific file | Control over the domain's DNS records, at any authoritative-nameserver level |
Works for a wildcard certificate | No — there's no single hostname to fetch a file from | Yes — this is the only method that can validate *.domain.com |
What it needs access to | Port 80 on the server the domain points to | An API token for the DNS provider, with permission to create and delete records |
Typical failure mode | Firewall blocking port 80, or DNS not yet pointed at the server | API token missing DNS-edit permission, or DNS propagation not finished before Let's Encrypt checks |
How do you actually turn this on in Coolify?
In Coolify, go to Servers → your server → Proxy, where the default configuration uses HTTP-01 (the http challenge) for Traefik's certificate resolver.
Add CF_DNS_API_TOKEN as an environment variable for the proxy, set to a Cloudflare API token generated specifically for this purpose — not a reused general-purpose token.
Change the certificate resolver's challenge configuration to the DNS challenge, with the provider set to cloudflare — the Traefik flag is --certificatesresolvers.letsencrypt.acme.dnschallenge.provider=cloudflare.
If DNS-01 validation fails intermittently, add a delay before Traefik checks for the TXT record's propagation — DNS writes aren't instant, and checking too early is a common false failure.
Restart the proxy so the new configuration takes effect, then request a certificate for *.yourdomain.com the same way any other domain gets one added in Coolify.
Separately, set the server's Wildcard Domain field (in the server's general settings) to the base domain — this is what makes every new resource on that server get an automatically generated subdomain, rather than needing a manual DNS entry each time.
That last step is worth calling out on its own, because it's easy to conflate with the DNS-01 setup and they're not the same thing. Coolify's server-level Wildcard Domain field controls automatic subdomain assignment for resources — it's a convenience feature, and it exists independent of how the certificate for that wildcard actually gets issued. Coolify's own documentation is explicit that the built-in Coolify Proxy flow won't issue SSL certificates for catch-all domains on its own; the DNS-01 configuration above is what actually makes a real wildcard certificate exist. Without it, the Wildcard Domain setting can assign subdomains, but Coolify has nothing valid to present for HTTPS on any of them. The XenGrowth resource library covers the the operations side of this side of this.
What Cloudflare API token permissions does this actually need?
The least amount that gets the job done, and Cloudflare makes that easy to enforce: create a token scoped to Zone → DNS → Edit, restricted to the one zone this covers, rather than an account-wide token or one of the broader legacy Global API Key credentials. This isn't a theoretical security nicety — this token lives in an environment variable on a server that's reachable from the internet, and the blast radius of it leaking is the difference between "someone can edit DNS for one domain" and "someone can edit DNS, and potentially more, for every zone on the account." Cloudflare's own guidance is explicit about scoping tokens to the specific zone rather than granting broader access, which is exactly the principle at stake here.
Create a dedicated token, not a reused one — if it needs rotating later, nothing else breaks
Scope it to Zone:DNS:Edit on the specific zone the wildcard covers, not the whole account
Store it as CF_DNS_API_TOKEN on the proxy only — it doesn't need to exist anywhere else in the stack
Rotate it if it's ever pasted into a shared chat, a public repo, or anywhere outside Coolify's own environment variable storage
Does Cloudflare's orange-cloud proxying interfere with any of this?
Not with the certificate issuance itself — DNS-01 validation happens entirely through Cloudflare's API, checking a TXT record, which has nothing to do with whether traffic to the domain is proxied through Cloudflare's network or resolves directly. This is actually one of DNS-01's practical advantages over HTTP-01 in a Cloudflare setup: HTTP-01 needs port 80 reachable on the origin, which can get tangled with Cloudflare's own SSL/TLS mode settings and proxying; DNS-01 sidesteps that whole path because it never touches the HTTP layer at all. What proxying does affect is what happens after the certificate exists: a subdomain that's proxied (orange cloud on) is served through Cloudflare's edge, gets the benefits described in what Cloudflare's free tier actually does for a self-hosted app, and hides the origin IP from casual lookups; a subdomain left unproxied (grey cloud) resolves straight to the VPS, which is sometimes deliberately what you want for a preview environment where Cloudflare's caching would otherwise get in the way of seeing changes immediately.
Setup choice | What it affects | When to use it |
|---|---|---|
Cloudflare proxy on (orange cloud) | Traffic to that subdomain, and only that — never certificate issuance | Production apps that want the CDN, WAF, and origin-hiding benefits |
Cloudflare proxy off (grey cloud) | Same — traffic resolves directly to the VPS | Preview or staging subdomains where you want to see changes without a cache layer in the way |
DNS-01 challenge configured | Certificate issuance for the wildcard itself | Required once, regardless of whether any given subdomain ends up proxied or not |
What actually goes wrong when the DNS-01 challenge fails?
Almost always one of two things: the API token doesn't actually have permission to write the TXT record it's trying to create, or Traefik checks for that record before Cloudflare's DNS has finished propagating it. The first shows up as an authentication or permission error in the proxy's own logs, immediately, and it's usually a token generated with the wrong scope or the wrong zone selected when it was created. The second is quieter — the challenge times out looking for a record that does exist, just not yet where Traefik happened to check for it — and it's exactly what the propagation delay setting exists to absorb. Neither failure is rare on a first attempt, which is worth knowing going in so it doesn't read as a sign the whole approach is broken. For the AI agents and marketing automation angle, see XenGrowth on governed AI marketing workflows.
Token error in the logs: regenerate the token, double-check it's scoped to Zone:DNS:Edit on the correct zone, and confirm it hasn't been pasted with a trailing space or missing character
Challenge times out waiting for the TXT record: add or increase the propagation delay before Traefik checks, since Cloudflare's own DNS writes aren't instantaneous
Works for the base domain but not the wildcard specifically: confirm the certificate request actually includes *.yourdomain.com, not just yourdomain.com — these are two separate identifiers to Let's Encrypt even on the same certificate
Repeated failed attempts start getting rejected outright: that's the authorization-failure rate limit — five per identifier per hour — so fix the underlying cause first rather than immediately retrying
What if Cloudflare only handles DNS and something else handles the app's traffic?
That's actually the common case, and it doesn't change anything about the certificate side. DNS-01 validation only cares whether the API token can create and read a TXT record on the zone — it has no opinion on whether traffic to that domain is proxied through Cloudflare, sent straight to the origin, or routed through something else entirely. As long as Cloudflare is the authoritative DNS provider for the zone (nameservers pointed at Cloudflare, which is the default setup for any domain added to a Cloudflare account), the API token can manage records for it regardless of what's actually serving HTTP or HTTPS traffic for that domain. The two concerns — who answers DNS queries, and who answers HTTP requests — are genuinely separate, and DNS-01 only ever touches the first one.
The one place this distinction does matter is if a domain's nameservers were never actually moved to Cloudflare — a subdomain merely added there while the parent zone lives elsewhere. In that case Cloudflare's API has nothing authoritative to write a TXT record against, and the DNS-01 challenge fails for a reason that has nothing to do with the token or Traefik's configuration at all. Checking that the zone genuinely lives in Cloudflare, before troubleshooting anything else, saves a fair amount of confused debugging the first time this comes up. XenGrowth on building one SEO and GEO content system goes further into AI search, GEO and discovery.
A wildcard certificate isn't proven by anything the wildcard actually serves. It's proven entirely through DNS, which is the one part of this that never has to wait for a subdomain to exist first.
What does this actually unlock once it's working?
Per-branch preview subdomains, mainly — feature-branch.yourdomain.com or pr-42.yourdomain.com getting a real, valid HTTPS URL the moment a deploy exists, with no manual DNS entry and no manual certificate request per branch. Once the wildcard certificate exists and Coolify's Wildcard Domain setting is pointed at the base domain, every new resource can be handed a subdomain automatically as part of the same deploy flow described in the git-push-to-production workflow — the certificate problem that would otherwise block this entirely is already solved before the first preview branch is ever pushed.
That's the actual payoff, and it's worth being clear it's not a small one: a genuinely unlimited number of working, HTTPS-valid preview environments, for the cost of one wildcard certificate and one API token scoped correctly. Compared to running a separate DNS-01 setup or paying for a platform that bundles this in, the entire mechanism here is free — the only thing spent is the fifteen minutes it takes to configure the DNS challenge once.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
For the marketing and revenue operations view of wildcard domains with coolify and Cloudflare, see XenGrowth's growth operations team.
Four questions on wildcard DNS and the certificate step that catches people out. The DNS half is easy; the validation half is where the afternoon goes.
