Skip to main content
Marketing (apps/marketing) is part of the TTR D74 Cloudflare migration, moving public marketing and legal pages from Vercel to native Cloudflare Workers powered by TanStack Start, Vite+, and Void SDK. Its request context, Next.js shims (next/headers, next/navigation, next-intl/server), Vite preset, and response policies come from @tuturuuu/start-bridge. The application maintains its own Worker entrypoint (cloudflare/worker.ts), route tree, and layout hierarchy.

​
Worker identity and mounts

The Worker targets the following staging and production identities:
  • Worker Name: tuturuuu-marketing (production and staging candidate)
  • Root Hosts: marketing.tuturuuu.com
  • Mount Hosts: tuturuuu.com
  • Base Path: /marketing
On the apex domain (tuturuuu.com), pages are mounted under /marketing/* or routed via Cloudflare path routing rules. On the canonical subdomain (marketing.tuturuuu.com), pages are served directly from /.

​
Bindings and configuration

The Worker requires only standard asset and routing bindings; no secrets are placed on the Cloudflare Worker.

​
Route groups and ownership

Route outcomes are declared in start-bridge.routes.json under runtime and verified against workerd during CI qualification.

​
Pass-through routes (retained in apps/web on Vercel)

The following routes are intentionally not ported to the Worker and stay in apps/web on Vercel as gateway pass-through routes:
  • /download
  • /models
  • /changelog (including [slug] articles and dynamic OG/Twitter image routes)
Rationale: These surfaces rely directly on the Supabase admin client (createAdminClient) with SUPABASE_SECRET_KEY, and /download depends on per-request client detection headers. apps/web does not provide dedicated public APIs for these operations. Injecting service-role credentials into the public Cloudflare Worker is forbidden, and adding new backend endpoints would require modifying apps/web (which is kept strictly untouched during this migration). Routing rules on Cloudflare forward these paths directly to the Vercel deployment.

​
Build and local verification

Local build prerequisites require compiling workspace package distributions first so that Rolldown resolves dependencies:
To run runtime verification and type checks:

​
Cutover and rollback runbook

​
Prerequisites

  1. Vercel deployment ID: The prior Vercel deployment ID is not recorded in the repository. Rex must capture and record the active immutable Vercel deployment ID and domain configuration before applying routing rules.
  2. Untouched origin: apps/web remains deployed and functional on Vercel; no destructive changes or deletions are performed on the Vercel origin.

​
Traffic cutover

  1. Traffic cutover is performed progressively via Cloudflare route patterns assigned to the Worker.
  2. Cloudflare routes are applied per page group (e.g. /privacy, /terms, /security/*, etc.).
  3. Once routed, verify live smoke responses immediately.

​
Smoke verification

Verify status codes and runtime identification header x-tuturuuu-runtime: native:
All status codes must return 200, and x-tuturuuu-runtime must equal native.

​
Rollback procedure

There is no in-repo gateway feature flag per page group.
  • Mechanism: Per-group rollback is executed by removing that group’s Cloudflare route pattern (owned by Rex).
  • Behavior: Because apps/web on Vercel remains running and completely untouched, deleting or disabling the Cloudflare Worker route pattern immediately restores Vercel as the origin for that page group with zero downtime.
  • RTO: Under 5 minutes without requiring repository commits or code rebuilds.