cloudflare-ops

name	cloudflare-ops
description	Cloudflare for DNS, R2 object storage, CDN and domains. Load before changing DNS records, creating or configuring R2 buckets, issuing storage credentials, pointing a domain at the VPS, or diagnosing anything served through a 9nau.com / client subdomain.

Cloudflare

Account: [e-mail] · Account ID 6cc895a1e69eb42b6690f9c41ae57506.

Cloudflare fronts DNS for the domains, serves the CDN, and holds R2 object storage for naŭ and for client projects.

Two sets of credentials — they are not interchangeable

wrangler (v4.84.1, OAuth, already logged in). Scopes: account:read, user:read, workers:write, workers_kv:write, workers_routes:write, workers_scripts:write, workers_tail:read, d1:write.

It can list R2 buckets, but it has no DNS scope and no R2 write scope. Reaching for wrangler to change a DNS record will fail with a permissions error that reads like a bug.

A separate API key with DNS and other permissions, held by Samuel. Ask him for it when a task needs DNS; do not assume it is in the environment.

R2 S3 credentials are a third thing again — access key / secret pairs issued per use in the R2 dashboard, used by rclone and by the services. These are what applications carry in their .env. An expired one of these is what silently broke the platform backup for weeks, so when a service reports 401 Unauthorized against R2, suspect the S3 credential rather than the account.

A custom domain makes the whole bucket public

This is the single most expensive thing to get wrong here. Binding a custom domain to an R2 bucket publishes every object in it, not just the prefix you had in mind. media.9nau.com is bound to nau-storage, so nau-storage/backups/ was world-readable for three months — full database dumps, downloadable by anyone who guessed the path.

Never put anything private in a bucket that has a domain bound, however obscure the prefix. Give it its own bucket instead. A WAF rule blocking the path is not equivalent: the object stays public-capable and the protection lasts exactly as long as the rule does.

Deleting an object does not purge the CDN. Cloudflare keeps serving the cached copy, and GET and HEAD cache separately — a HEAD returning 404 says nothing about GET. After deleting anything sensitive, purge the cache explicitly and re-verify with GET.

Purging needs a token with Zone → Cache Purge. Neither the wrangler OAuth token nor CLOUDFLARE_DNS_API_TOKEN has it.

R2 buckets

Bucket	Created	Used by
nau-storage	2026-04-18	naŭ Platform. Zazu voicenotes at {env}/zazu/voicenotes/{telegramId}/{uuid}.ogg; mobile captures; served publicly via media.9nau.com
nau-backups	2026-08-21	Private, no domain bound. Encrypted database dumps. Never bind a domain to this
violeta-storage	2026-07-09	Violeta Cuesta client project
r2-asset-manager	2026-01-18	Older asset tooling — the r2-asset-manager repo is in deprecated/, so treat this bucket as legacy and confirm before writing to it

Endpoint form: https://6cc895a1e69eb42b6690f9c41ae57506.r2.cloudflarestorage.com

Services do not get bucket credentials to hand out. The API issues presigned upload URLs (POST /media/upload-request) and the client PUTs directly to R2 — keep that shape rather than shipping keys to clients, and never to a mobile binary.

Different services hold different R2 credentials on purpose. Zazu's key is separate from the backup job's, which is why Zazu's voicenote uploads kept working while backups failed. Preserve that separation: one dead credential should not take down everything.

DNS and domains

9nau.com is the platform domain. Subdomains in use: api, app, accounts, media. zazu.9nau.com was retired along with the Zazu dashboard — do not recreate it.

All application subdomains point at the Hetzner VPS, where nau-gateway terminates TLS and routes. Adding a service means: DNS record → gateway route → container on the internal network. The container itself never binds a public port.

Client domains (Karen Explora, Violeta Cuesta, Andi Universo, Polar) are also managed here and also land on the same VPS. Before changing any DNS record, confirm which project owns it — this account holds domains for several unrelated businesses.

Before changing anything

DNS changes are fast to make and slow to notice when wrong. State the current record, the intended record, and what breaks if it is wrong, before applying. TTL and proxy status (orange cloud vs grey) matter: proxied records hide the origin IP and enable the CDN; unproxied ones expose it. Default to proxied for anything web-facing.