Landing pages and landing-page QA
Keeps the versions, previews, QA evidence, publish state, and experiments of landing pages that are built outside Apex and deployed with the CLI.
Simple terms
You build a landing page in a workspace checkout and deploy it with the Apex CLI. Apex keeps every version, shows its preview and QA evidence, publishes it, and runs experiments on it.
Keeps the versions, previews, QA evidence, publish state, and experiments of landing pages that are built outside Apex and deployed with the CLI.
Routes
/landing-pages/landing-pages/new(redirects to the list with a deploy notice)/landing-pages/[id]/landing-pages/[id]/qa
Implementation behavior
- Landing pages have typed page records, versions, publish status, preview URLs, and immutable published bundles.
- Pages are built outside Apex. The in-app page builder (brief, compose, chat, blocks, and gates) was retired on 2026-10-02.
- Each deploy adds an immutable version. QA checks a specific version before it becomes the published one.
- Published bundles are served through the configured landing-page runtime and storage path.
How to use it
- Build the page in a workspace checkout, then run
apex landing-pages deploy. - Open the page in Apex to preview each version and review its QA evidence.
- Publish only after the QA route shows the intended version and target.
- Unpublish to take a page offline, or archive it to take it offline and grey it out in the list.
When not to use it
- Do not use landing pages for a small change to an existing product page; use an experiment variant instead.
- Do not publish a version that has not been previewed and QAed.
Implementation source
- Pages live under
src/app/(dashboard)/landing-pages. - Handlers include
/api/landing-pages,/api/landing-pages/[id]/publish,/api/landing-pages/[id]/qa,/api/landing-pages/[id]/experiments, and version render routes. - Brief and grounding reads (
/api/landing-pages/briefs,/api/landing-pages/grounding/*) give a workspace checkout the catalog, offers, reviews, and brief data to build from. - Landing page records, versions, artifacts, and publish state are persisted separately from experiment variations.
Data and API
- Landing page, version, QA, publish, and artifact records.
- APIs under
/api/landing-pages,/api/landing-pages/[id]/publish,/api/landing-pages/[id]/qa,/api/landing-pages/[id]/versions/[versionId]/render, and/api/landing-pages/preview/[versionId]. - The public v1 API (
/api/v1/landing-pages) is read-only and backs the CLI's landing-page reads.
Failure modes
- Preview mismatch: make sure the version being QAed is the latest deployed version.
- Publish target unavailable: check storage and runtime configuration and the deployed bundle state.
MP4 (video/mp4) and WebM (video/webm) videos are hosted directly by Apex.
Each version holds at most 300 files and 100 MB; each video is limited to 50 MB,
and other files to 3 MB. apply automatically obtains a 15-minute upload grant
for videos above 3 MB and sends resumable 8 MB parts straight to the Worker,
retrying failed parts with progress output. The Worker verifies the declared
size and SHA-256 before apply records the file. Pull and signed previews also
fetch large videos directly from the Worker. Video supports byte ranges,
including Safari's bytes=0-1 probe; rollback preserves the older bytes.