chore(ops): move to a domain we control and proxy the origin through Cloudflare #313
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: bermudalamb/redefined-designs#313
Reference in New Issue
Block a user
Follow-on from #285, which established that Cloudflare's free tier cannot be applied to
bermudalamb.synology.meat all — the free plan supports only full setup, which needs nameserver delegation for the zone, and the zone is Synology's. Partial (CNAME) setup is Business/Enterprise. The findings are indocs/ops/cloudflare-free-tier.md.So origin hiding is blocked behind owning a domain. This issue is that migration.
This is not a DNS change. The hostname is embedded in outstanding emails, session cookies and signed links, and the application's proxy assumptions are wrong the moment a second proxy exists. Most of the work below is not Cloudflare configuration.
Scope
Register a domain we control, put its zone on Cloudflare, proxy the storefront through it, and keep the NAS as the origin behind DDNS.
The registrar decision
The registrar does nothing for origin hiding on its own — only the Cloudflare proxy does. Buying a domain and using the registrar's own DNS publishes the house IP exactly as today. The registrar's whole job is to own a zone we can delegate to Cloudflare, cheaply.
Proposed: Cloudflare Registrar. Cheapest, and its one restriction — no external nameservers — is the thing we actually want here. The trade-off is lock-in: leaving Cloudflare later means transferring the domain out, not repointing NS. Porkbun is the hedge if that flexibility is wanted, at about a dollar a year more.
Prices are from third-party comparison sites as of 2026-09-05, not each registrar's own pricing page. Confirm at purchase.
Two things that must ship in the same change as the DNS cutover
1.
trust proxyis wrong the moment Cloudflare is in frontapp.ts:34setsapp.set('trust proxy', 1). Today the chain isclient → NPM → appandreq.ipis the real client. Cloudflare appends toX-Forwarded-Forrather than replacing it, so the chain becomesclient → Cloudflare → NPM → appandreq.ipresolves to a Cloudflare edge address.Four limiters key on
req.ipand would silently stop distinguishing callers while continuing to look healthy — one abusive client would spend everybody's allowance:passwordResetRequestLimiter(viakeyByCallerAndEmail)clientErrorLimiter(nokeyGenerator, so it defaults to IP)intakeViewLimiterintakeSubmitLimiterverificationResendLimiteris unaffected; it keys on customer id.Fix is
trust proxy: 2, or readCF-Connecting-IPand validate the peer against Cloudflare's published ranges. The comment atrateLimit.ts:62-64asserts the current behaviour as fact and has to change in the same commit, or it becomes a lie that the next person will believe.This is latent for any second proxy, not only Cloudflare.
2. The
proxiedflag is a silent-failure trapThe home IP is dynamic, so a DDNS updater must keep the Cloudflare A record current via their API. That API call carries a
proxiedboolean.If the updater ever writes
proxied: false, the origin IP goes public and nothing breaks. The site keeps serving, so there is no signal — the protection is simply gone. Same shape as thetrust proxyproblem: correct-looking behaviour, absent protection.Requirements:
proxied: trueon every write, never inherit it.One upside: with a proxied record, visitors always terminate at Cloudflare, so an origin IP change needs no client-side DNS propagation. Strictly better than plain DDNS today.
The migration surface
Verified in the code rather than guessed:
docker-compose.prod.yml:191hardcodesPUBLIC_URL=https://redefined-designs.bermudalamb.synology.me.PUBLIC_URL:envValidation.ts,favoriteAlerts.ts,intake/actionLinks.ts,intake/notifyDraft.ts,routes/adminUploadLinks.ts,routes/customers.ts,server.ts,utils.ts.UPLOADS_BASE_URLis a separate origin and needs deciding alongside.docker-compose.qa.ymlcarries the QA hostname in its documented env block.^/(admin|api/admin). That config is not in this repo and has to move with the hostname. Per decision 5 inproject-context.md, do not widen or narrow that regex in the process.gitea.bermudalamb.synology.me) resolves to the same address and the Actions runner needs it. Left unproxied it republishes the IP; proxied, Bot Fight Mode may challenge the runner.The cutover window
Outstanding links and cookies already in customers' hands, with the values checked:
ACTION_TTL_MS)SESSION_DAYS)verify_token_hours)password_reset_hours)So the old hostname has to keep answering for at least 30 days after cutover, or outstanding intake action links die. The logout is unavoidable and worth deciding whether to announce.
Upload-link expiry was not established —
adminUploadLinks.tsbounds submissions withmax_submissionsand no expiry was found. Confirm before cutover.Decisions this issue needs to make
POST /webhooks/paypalis a capture notification we never receive. Safe answer is off.ssl_verify_client on;durably was not established in #285.Out of scope
Done when
digagainst the public record returns Cloudflare, not the house.trust proxyis corrected andrateLimit.ts:62-64says something true, shipped in the same change.proxied: trueon every update, with something checking it stays that way.docs/ops/cloudflare-free-tier.mdis updated to reflect what was actually adopted, rather than being left as a spike that recommended not adopting.Refs #285
Domains registered — the prerequisite is met
Registered at name.com on 2026-09-06:
redefined-designs.comredefined-designs.netredefined-designs.inforedefined-designs.orgThis settles the blocker this issue was filed for. The registrar comparison above is superseded — the choice was made and the domains are bought, so the Cloudflare Registrar proposal in the issue body is now historical rather than a recommendation. name.com is a full registrar with nameserver control, which is all the Cloudflare free plan's full setup requires.
Domain Lock Plus blocks the nameserver change
This is the part that will bite during the cutover. Domain Safe includes Domain Lock Plus, which by design prevents changes to the domain's nameservers, alongside blocking external transfers and contact/WHOIS changes. It pairs with the account's two-step verification.
Delegating to Cloudflare is a nameserver change, so the cutover sequence has an extra step at the front and back:
Re-enabling afterwards costs nothing operationally: once the zone is delegated, ongoing DNS changes — including the DDNS updater rewriting the A record — happen at Cloudflare, not at name.com, so the lock never sits in the way again.
Two consequences of that same fact, worth knowing rather than discovering:
proxiedflag gets flipped — that still needs its own check, per the trap described in the issue body..orghas no Domain Safe ProThree of the four carry it and
.orgdoes not. Deliberate or an oversight? It matters less than it looks — the lock's value is concentrated on whichever domain actually serves the site — but if.orgis meant to be defensive-only it is also the one an attacker would find least protected, so it is worth a conscious answer rather than leaving it as an accident.Decisions this unblocks, and now needs
redefined-designs.com. That value becomesPUBLIC_URLand propagates into every verification email, password-reset link, upload link and intake action link, so it is not a decision to revisit later — see the migration surface in the issue body.qa.redefined-designs.com, say) or stays on the Synology DDNS name. The issue body already flags that leaving QA on the old address republishes the origin IP and defeats the exercise — now there is a domain to move it to.Everything else in the issue body still stands, in particular the two items that must ship in the same change as the DNS cutover: the
trust proxy: 1 → 2correction withrateLimit.ts:62-64, and assertingproxied: trueon every DDNS write.Correction on
.orgThe previous comment asked whether
.orglacking Domain Safe Pro was deliberate or an oversight. It is neither — name.com does not appear to offer it for.org, so there was nothing to choose.Worth being honest about the evidence: name.com's public documentation for Domain Safe does not publish a supported-TLD list at all, so this is an observation from the account rather than something confirmed against their docs. If it ever matters enough to rely on, their support is the only authoritative answer.
What that actually costs, and the mitigation
Domain Lock Plus restricts five things: external transfer to another registrar, internal transfer between name.com accounts, toggling WHOIS privacy, changes to contact/WHOIS records, and changes to nameservers.
Without it,
.orgfalls back to the standard registrar lock (clientTransferProhibited), which is free, supported everywhere, and is the mechanism that actually blocks an unauthorised transfer. The gap is therefore narrower than the product tiers suggest — what is lost is the 2FA-gated second layer and the protection against nameserver changes, not transfer protection outright.Two things to confirm rather than assume:
redefined-designs.org. It is on by default at most registrars, and it is the part that matters.Why this is low-stakes here
.orgwill not serve the site — the primary carriesPUBLIC_URLand everything derived from it. The realistic exposure is someone taking.organd standing up a lookalike storefront to phish customers.That risk exists regardless of this lock, and #285 already established it is not addressable on Cloudflare's free tier — brand protection and phishing takedown are a paid upper-tier product. So the defensive registration is doing the useful work here by denying the name to someone else; the lock tier on it is a second-order concern.
No change to the cutover plan. The Domain Lock Plus step in the previous comment applies only to whichever domain becomes primary, and that one has it.
Decided: the primary domain is
redefined-designs.comSettled on 2026-09-08. This is the one that goes on Cloudflare, carries
PUBLIC_URL, and becomes the origin behind the proxied record.That resolves the first of the three decisions listed above. The remaining two are still open:
.net,.organd.infodo — redirect to the primary, park, or leave unused. Only the primary needs a Cloudflare zone; adding all four multiplies configuration for no gain unless they are actually serving redirects.qa.redefined-designs.com) or stays on the Synology DDNS name. Leaving it on the old address republishes the origin IP and defeats the exercise, so this is not a neutral default.Worth restating because it constrains the cutover rather than being a detail:
PUBLIC_URLpropagates into every verification email, password-reset link, upload link and intake action link at the moment those are sent. Intake action links live 30 days, so the old hostname has to keep answering that long after the switch. Picking the primary is therefore the point of no return for links already in customers' hands — which is why it is recorded here rather than left in a chat.This is much cheaper than the issue body says, and the reason is temporary
The body was written for a live shop. Production is not live and has no customers, which removes most of the cost it describes:
The remaining work is
PUBLIC_URL, the authentik forward-auth config, the Gitea host, and the DNS itself. That is the whole migration surface while nobody is depending on the old address.This is the cheapest this will ever be, and it gets more expensive the moment the shop opens — every link sent from then on has to keep working.
The one thing that must not ship early
trust proxy: 1 → 2cannot be merged ahead of the DNS cutover. With only Nginx Proxy Manager in front, trusting two hops makesreq.ipresolve to something that is not the client, which breaks the four limiters in the direction that looks healthy. It is only correct once Cloudflare is genuinely in front.So it ships with the cutover, in the same change, exactly as the body says — not as preparation. The same applies to the
rateLimit.ts:62-64comment that asserts the current behaviour.Ordered sequence
Steps 1–5 are not code and are yours; 6 is the code change and is mine when you reach it.
redefined-designs.comto Cloudflare as a zone (free plan, full setup).proxied: trueon every write — never inheriting it. A write that quietly sets it false publishes the origin IP and nothing visibly breaks.PUBLIC_URLto the new host,trust proxyto 2 with therateLimit.tscomment corrected, and the authentik forward-auth config moved.Still open, and worth deciding before step 1
qa.redefined-designs.com), or stay on the Synology name? Staying republishes the same origin IP and defeats the exercise, so this is not a neutral default.POST /webhooks/paypalis a capture notification we never receive..net,.organd.infodo — redirect, park, or nothing.Not started
Nothing here is implemented. Steps 1–5 are outside the repository, and step 6 is deliberately not prepared in advance because merging it early is the failure mode described above.