Cloudflare — DNS, R2 i Access

Cloudflare és la capa d’edge de tota la infraestructura. Hi resolem tres coses: DNS, storage d’objectes (R2) i autenticació (Access). Tot passa pel límit abans d’arribar a nabu.

DNS

Cloudflare gestiona la zona ediacarastudio.com i tots els subdominis, i el domini està registrat a Cloudflare Registrar (renovació anual). El record A de cada servei apunta a nabu; el proxy de Cloudflare seu al davant.

Regla general: tot va proxiat (núvol taronja) perquè Access i el cache actuïn al límit. L’excepció confirmada és el broker MQTT, que va DNS-only (núvol gris) perquè Cloudflare no proxia TCP arbitrari. Quan un servei intern necessita que Coolify/Traefik emeti el seu propi Let’s Encrypt, també es deixa DNS-only.

Subdomini	Apunta a	Proxy
ediacarastudio.com / www	nabu (web)	Proxiat
api	nabu (API)	Proxiat
cdn	R2	Proxiat ✅
platform	nabu (Coolify)	Proxiat
docs	Cloudflare Pages	Proxiat
labs · status	nabu	Proxiat (Access)
analytics	nabu (Umami)	DNS-only ✅ (first-party, fora de Cloudflare)
mqtt	nabu (Mosquitto)	DNS-only ✅

A verificar

Falta confirmar i documentar: el mode SSL/TLS (Full o Full strict) i si DNSSEC està actiu.

R2 — storage d’objectes

R2 dona storage d’objectes compatible amb S3, servit per cdn.ediacarastudio.com (TLS 1.3, proxiat). El bucket és ediacarastudio-assets. S’hi guarden els assets estàtics i les dades del mapa.

Un bucket, dos productors

El mateix bucket l’alimenten dos repositoris amb cicles de vida diferents:

Productor	Què hi escriu	Path	Com
assets	Brand assets (logos, fotos, docs)	arrel (shared/…, ediacarastudio-web/…)	CI: rclone sync en push a main
geodata	Dades del mapa (pmtiles, glyphs)	shared/maps/	Manual: rclone copy

Per què copy i no sync a geodata

Com que el bucket és compartit, geodata fa servir rclone copy limitat a shared/maps/ — un rclone sync mirroraria i esborraria els brand assets de l’altre productor. assets sí que pot fer sync perquè opera sobre tot el bucket des del seu dist/. Aquest coneixement no es dedueix del codi: documentat aquí a propòsit.

Facturació i cache

R2 factura operacions de lectura (Class B), no l’egress. Per això els objectes es serveixen amb Cache-Control llarg (max-age=31536000, immutable) i el trànsit pesat —les tiles del mapa— porta una capa extra de regles de cache/CORS/WAF descrita a Hardening del CDN per al mapa. Així les lectures d’R2 cauen a prop de zero independentment del trànsit.

Email Routing

Cloudflare Email Routing gestiona el correu entrant del domini: reenvia les adreces @ediacarastudio.com cap a les bústies reals (Gmail). És només reenviament — no envia.

No s’ha de confondre amb Resend, que és l’enviament transaccional (sortint) des de l’API. Un rep i reparteix; l’altre envia. Les adreces concretes i el seu estat són a Enllaços i correus.

Pages — llocs estàtics

Cloudflare Pages allotja els llocs purament estàtics, com aquest de docs. Connectat al repositori de GitHub, construeix a l’edge (els builders de Cloudflare) a cada push i publica el resultat — el build no toca nabu. Es protegeix amb una aplicació d’Access igual que qualsevol subdomini intern.

Access — auth al límit

Cloudflare Access és la capa d’autenticació. Protegeix els subdominis interns (docs, labs, dashboards) demanant identitat abans de deixar passar el trànsit cap a Traefik/Coolify. L’auth viu al límit — el projecte de darrere no porta codi d’auth.

El patró: un Access Group reutilitzable

En lloc de configurar usuaris a cada aplicació, definim un Access Group reutilitzable — p. ex. “ediacarastudio members” — i el referenciem des de múltiples aplicacions (un subdomini = una aplicació). Afegir o treure algú es fa en un sol lloc.

Aspecte	Detall
Cost	Tier gratuït fins a 50 usuaris
IdP	GitHub, social login o OTP per email
Granularitat	Una aplicació Access per subdomini, totes apuntant al mateix grup
On actua	Al límit (edge), abans de Traefik/Coolify

Així, un subdomini nou intern només necessita una aplicació Access que apunti al grup existent — sense tocar res del servei.