Preparing a Cloudflare Zone for Public URLs¶

An App Server gets a public URL by being served through Cloudflare: anti-DDoS, WAF and cache in front, the origin IP hidden. The zone that carries those URLs — muppy.cloud for the muppy.io service, or your own — needs a handful of settings that Muppy cannot apply for you, because they are bought or switched on in the Cloudflare dashboard. This page lists them once, in the order they are applied.

Tenants never touch this zone directly. Each tenant's Muppy writes its records through an MBD Client domain such as <client>.<zone>, and the MBD Server that holds the Cloudflare credential lives on the zone owner's side. What follows is the zone owner's checklist.

Why the defaults are not enough¶

Cloudflare's free Universal SSL certificate covers the zone apex and one level of subdomain: *.muppy.cloud. A tenant URL such as app.acme.muppy.cloud sits two levels down and is served with no valid certificate at all. Two Cloudflare add-ons close that gap:

Add-on	What it gives	Price
Advanced Certificate Manager (ACM)	edge certificates at any depth, and the switch below	10 $ per month, per zone
Total TLS (needs ACM)	one certificate issued automatically for every proxied hostname, at any depth, with domain validation handled by Cloudflare	included with ACM

Both are available on every plan, the Free plan included; a payment method must be on the account. Total TLS issues a certificate about a minute after a proxied record appears — until then the URL answers a TLS error, which the App Server's system health check shows as a transient red state.

The zone¶

Step	Where in the dashboard	Setting
1	Domain Registration, or your registrar	the zone is registered, and its nameservers point at Cloudflare
2	Add a site	the zone is added in full setup: Cloudflare is its authoritative DNS. Status Active
3	Zone → Overview	the Free plan is enough
4	SSL/TLS → Overview → Configure	encryption mode Full. Flexible would reach the origin over plain HTTP; Full (strict) only once every origin serves a certificate Cloudflare can verify
5	SSL/TLS → Edge Certificates → Advanced Certificate Manager	Activate
6	SSL/TLS → Edge Certificates → Total TLS	choose a certificate authority, then enable
7	SSL/TLS → Edge Certificates → Universal SSL	leave enabled: it still serves the zone's own first-level names
8	SSL/TLS → Edge Certificates	Always Use HTTPS on, Minimum TLS Version 1.2
9	Security → Bots → Bot Fight Mode	leave off: it blocks API clients and health checks
10	Security → WAF → Managed rules	the free Cloudflare Managed Ruleset is the one available on the Free plan

Total TLS: never delete a certificate by hand

Deleting a Total TLS certificate from the dashboard excludes that hostname from every future issuance, even if its record is recreated. Records come and go with App Servers; certificates are Cloudflare's to manage.

Let's Encrypt as the Total TLS authority

Let's Encrypt limits new certificates to 50 per week per registered domain, and every proxied hostname of the zone counts. A zone that expects bursts of new App Servers is better served by Google Trust Services, which has no such published cap.

The API token¶

The MBD Server needs one token with three permissions:

Permission	Level	Used for
Zone	Read	resolving the zone id when the domain connects
DNS	Edit	the tenants' A, AAAA, CNAME and TXT records
SSL and Certificates	Edit	custom hostnames (below) and reading certificate status

Cloudflare offers two kinds of token. Both carry the same permissions; they differ in who owns them and in how the permission picker is laid out.

Kind	Where	Owned by	Picker
User API token	My Profile → API Tokens → Create Token → Custom token	the person who creates it: it dies with their user account	a flat list: Zone → Zone, Zone → DNS, Zone → SSL and Certificates; scope under Zone Resources → Include → Specific zone
Account API token	Manage Account → Account API Tokens → Create Token	the Cloudflare account: it survives a person leaving, so use it for a production MBD Server	grouped by product: DNS & Zones → Zone (Read) and DNS (Edit), Cache & Performance → Zone SSL & Certificates (Edit); the Search for permission groups box finds a row by name; scope under Specified Domains

Name the token Muppy MBD <zone> @ <MBD Server>, for example Muppy MBD example.cloud @ h.example.cloud: the name says what the token is for, which zone it covers and which instance holds it, which is what you look for in the token list the day one has to be revoked.

Restrict the token to the one zone. Add Client IP Address Filtering with the MBD Server's public IP when it has a fixed one. The token goes into a Vault of type Cloudflare API Token on the MBD Server instance, and nowhere else. Muppy reads the token's own expiry when the domain connects and shows it on the DNS Domain, so a dated token is visible before it expires.

A token with DNS Edit reaches every record of the zone. There is no way to scope one to a subdomain, and Muppy has no way to detach a record from a zone without deleting it at Cloudflare: treat the instance that holds the token as an operator of the whole zone.

The zone in Muppy¶

On the MBD Server instance:

A DNS Domain for the zone, provider Cloudflare DNS, with the vault above. Connect. Leave Proxied by Default unchecked: the proxy is asked per record by each tenant's MBD Client, and a zone-level default would proxy records tenants did not ask for.
One MBD Server domain per tenant, <client>.<zone>, backend set to the zone, with the tenant's SigV4 token.

On each tenant's instance, an MBD Client domain of the same name, with Proxied by Default (via MBD Server) ticked. The rest — records, TTL, certificates — follows from the App Server configuration described in Network Configuration.

Sync the CloudflareIPsV4 and CloudflareIPsV6 Dynamic CIDR Ranges once on every instance that runs a Traefik host for public applications, and attach them to that host: its firewall then admits Cloudflare's edge only on port 443. The ranges are fetched by the range's Sync button, never at module update. Attach the same two ranges to the Traefik server's Trusted forwarding proxies as well if any application on it must filter its own visitors rather than the edge; see Network Configuration.

Custom hostnames (tenants' own domains)¶

A tenant who wants erp.example.com rather than erp.acme.<zone> is served by Cloudflare for SaaS: the tenant creates one CNAME to its <zone> name, Cloudflare issues the edge certificate for the custom name and routes it to the tenant's proxied record. One hundred custom hostnames are included per zone, then 0,10 $ per hostname per month.

Step	Where in the dashboard	Setting
1	SSL/TLS → Custom Hostnames	Enable Cloudflare for SaaS
2	DNS → Records	an `A` record `fallback`, proxied, pointing at any origin that answers on 443
3	SSL/TLS → Custom Hostnames → Fallback Origin	`fallback.<zone>`, then Add Fallback Origin

The fallback origin is required by Cloudflare and never reached in practice: every custom hostname Muppy creates carries its own origin, the tenant's proxied record. Wildcard custom hostnames (*.example.com) are an Enterprise feature and are not supported.