Skip to main content

Infrastructure

Moving HoopAI public site assets to Cloudflare R2

A website infrastructure account of the R2 asset path, build pipeline, runtime dependency caveat, and verification lessons.

3 min read

HoopAI's public website assets use cdn.hoopai.com, backed by the Cloudflare R2 bucket named hoopai-assets. The migration moved owned site files away from retired storage and established a taxonomy for new web, studio, shared, and CMS media. The path change also exposed an important engineering caveat: successful image delivery does not prove that the browser runtime can execute every script needed by replayed Webflow pages.

Why the asset path changed

The asset architecture places public marketing files behind HoopAI's Cloudflare domain and keeps R2 as the storage layer. Former Bunny-hosted files were migrated to the same public domain, while legacy externally referenced paths such as Stories, Flow Charts, and Videos remain frozen. Published paths are not renamed because external links and immutable caches can depend on them.

New files follow a kebab-case taxonomy under web, studio, or shared. CMS media belongs under a collection and document slug. This structure makes ownership visible and gives build or upload scripts a predictable destination. It also separates new managed paths from the frozen assets tree that supports the existing site.

The R2 build path

The recorded migration used a CDN-mode Astro rebuild to gather referenced files, rewrite large numbers of asset references, and upload the resulting keys through Wrangler. Verification checked several page types for broken images and residual mirror or Webflow asset references. CORS configuration was required for fetched JSON and font files, even though ordinary images could display without it.

Dynamic Webflow chunks and the upload tail required additional attention. Some scripts were loaded by the runtime and did not appear in the initial reference scan. A failed upload could also stop remaining workers and leave later files absent. The remediation checked every expected key, uploaded missing items, and accounted for brief cached 404 responses when probing a file before upload.

The runtime caveat

The first CDN flip passed asset checks while site interactions failed. The rewrite handled Webflow-hosted files but left an external jQuery dependency at a location that returned an error. Without jQuery, the Webflow runtime did not initialize, even though images, fonts, and other network requests looked healthy. The deployment was rolled back while the runtime path was corrected.

That incident changed the verification standard. A website asset migration has to test executed JavaScript and a real interaction, including the presence of jQuery and the Webflow environment, browser errors, and an element changing state after a click. Network success is one part of the evidence. It cannot stand in for functional behavior.

How the migration was verified

Current architecture records establish Cloudflare R2 as live storage and cdn.hoopai.com as its custom domain. The site build also guards against retired Bunny references. For new assets, verification should confirm the source file, immutable destination key, public response, content type, and rendered use on the relevant page.

Runtime checks remain necessary for files loaded indirectly by the Webflow replay. CORS should be configured before first use, expected keys should be compared with uploaded keys, and browser testing should cover both visuals and interactions. The durable result is an owned asset path with a documented exception process, rather than a one-time copy operation whose missing files surface only after publication.

Topics

Cloudflare R2CDNAsset pipeline