CedarCopilot wants to merge 2 commits into staging from fix/marketing-apex-flip
Live on prod, no production signal yet
Strict CloudWatch fallback saw 3,675 success-shaped log lines matching email, emails, gmail, mail, inbox, but no tied operation was present, so Libra is not calling this working.
Libra has verdicts on 0 of 1 tracked behaviors on prod; 1 is still being checked. Libra checks hourly for 3 days after each deploy.
Draft on purpose. This PR is the switch. Once it lands, the next prod frontend deploy , including one shipped for an unrelated reason , starts bouncing marketing paths to the apex and app paths back to mail.*. If the apex still 301s to mail.cedarcopilot.com at that moment, the result is a redirect loop on /pricing, /blog and /bookdemo.
Merge only after the Cloudflare cutover (apex redirect rule deleted, apex + www CNAMEd to d3dcq98iblzth4.cloudfront.net).
Stacked on #2628, which attaches the aliases.
Derive the marketing origin per environment in publish-frontend-assets.sh instead of carrying it as a deploy variable:
cedar_marketing_url_for_env() {
case "$1" in
staging) printf '\n' ;;
prod) printf 'https://cedarcopilot.com\n' ;;
esac
}
The apex is permanently the marketing home, so there is nothing per-deploy to decide. This matches how the app and API domains already resolve , a per-env default in code, overridable by env var.
Staging must stay empty rather than inherit the prod apex. With a marketing host set, useHostRouting would bounce mail-staging.cedarcopilot.com/pricing to production.
The host-split code itself (lib/marketing-host.ts, hooks/use-host-routing.ts, app/page.tsx) already shipped and has been inert; this is what activates it.
VITE_PUBLIC_MARKETING_URL still wins if set in the environment, so an urgent rollback needs no commit , set it to the app origin and redeploy the frontend, and both origins go back to serving the whole site. Longer term, point cedar_marketing_url_for_env at the app origin.
Change is 1 workflow YAML, 2 bash scripts, 1 markdown doc. Zero TS/JS.
cedar_marketing_url_for_env returns https://cedarcopilot.com for prod and empty for staging; sourcing it through the publish-frontend-assets.sh export path yields VITE_PUBLIC_MARKETING_URL="https://cedarcopilot.com" for prod and "" for staging (which hasSplitHosts() reads as not-split).bash -n clean on both scripts; workflow parses as valid YAML.pnpm run autofix:local was not run: every stage of it operates on application code this change cannot touch.
š¤ Generated with Claude Code
This PR activates production host splitting by deriving the marketing origin during frontend publication, keeps staging unsplit, and documents the CloudFront and DNS cutover.
The staging frontend artifact regression should be fixed before merging; the CI configuration mismatch is also worth aligning.
Exporting an empty staging marketing URL reaches the SEO generator without falling back to the staging app origin, producing relative robots and sitemap locations, while the pull-request build additionally exposes an override that production deployment ignores.
Files Needing Attention: aws/scripts/publish-frontend-assets.sh, .github/workflows/aws-builds.yml
| Filename | Overview |
|---|---|
| aws/scripts/publish-frontend-assets.sh | Adds the marketing URL build export, but its empty staging value produces origin-less SEO artifacts through the existing Vite configuration. |
| aws/scripts/deploy-utils.sh | Adds deterministic staging and production marketing URL defaults with unsupported-environment validation. |
| .github/workflows/aws-builds.yml | Builds the production frontend with the apex default, but introduces an override variable that the deployment path does not recognize. |
| aws/docs/marketing-domain-split.md | Documents the alias, certificate, DNS, cutover, |
Libra has not measured any production surfaces for this change yet.