HoopAI.com now follows one declared production path: Astro builds the site, Cloudflare Workers Static Assets serves the generated files, and the Worker named hoopai handles the production domains. This is a website infrastructure change, not a release of customer-facing product capability. The repository's project guidance records the canonical commands, account target, preview host, and coupling between the shipping Astro application and its required build-time donor.
The production hosting change
The canonical host is Cloudflare. The repository's origin remains the HoopAI Webflow GitHub repository, while the production deployment uses apps/astro/wrangler.jsonc. Both hoopai.com and www.hoopai.com are bound as custom domains to the same Worker. The documented preview address remains available for non-production checks before the production domain is inspected.
That declaration matters because the repository still contains Vercel files and historical deployment notes. They provide rollback and reference context, yet they do not define the current release route. A website change intended for production has one destination, which reduces the risk that a successful build is published to an inactive or secondary host.
What the Worker serves
Astro is the framework that builds and ships the site. Its generated apps/astro/dist directory is uploaded as static assets through Wrangler. The Next.js route tree in apps/web does not run a production build. Visitor requests receive the Astro output, including passthrough pages that replay Webflow markup and CMS routes that use the repository's React renderers inside the Astro shell.
The static deployment still carries a deliberate runtime model. Passthrough pages use MarketingShell, while CMS pages use CloneShell. Both retain Webflow CSS and the required interaction runtime. Hosting the output on Cloudflare changes where files are served. It does not replace the page architecture or authorize a from-scratch rewrite of the exported pages.
How deployments are verified
The documented release sequence builds with pnpm --filter @hoop/astro build and deploys with Wrangler from the Astro package. Verification continues after the upload. The production domain, rather than only the preview hostname, must serve the new build. That check catches domain binding, caching, or routing problems that a successful Worker deployment message cannot reveal.
Build verification also protects runtime dependencies. The project record describes a prior outage caused by a failed jQuery path and notes the guard that rejects an external code.jquery.com reference in generated output. The current guidance states that jQuery is self-hosted and used by both replay paths. A release is complete when the built files, domain response, and required browser runtime agree.
The build-time donor that remains
apps/web remains essential even though its Next.js routes are inactive in production. Astro takes its public directory from apps/web/public, resolves an alias into apps/web/src, reads environment configuration from the donor app, and loads hundreds of island HTML sources stored under its public tree. Removing that directory would break the shipping build.
This distinction prevents a dangerous cleanup mistake. Dead route execution does not mean dead repository material. The donor contains CMS renderers, shared chrome, assets, environment input, and the Webflow island documents used by Astro. Future infrastructure work has to separate those dependencies deliberately before any directory can be retired.
