CDN builds

One command

The site SDK ships a CLI that wraps the whole flow — wire it in as the site's build script:

npx localplug build           # next build + upload changed assets + activate
npx localplug build --dry-run
npx localplug status          # active deployment + the site's asset prefix

(The command name follows the platform's own SDK branding; the flow underneath is the site CDN surface: manifest → upload → activate → status.)

The order of operations matters

1. Resolve the CDN prefix first. The asset prefix must be known before next build — a runtime-only prefix silently kills hydration (a frozen page with zero console errors). The build runs with NEXT_PUBLIC_ASSET_PREFIX baked in, and next.config reads it:

assetPrefix: process.env.NEXT_PUBLIC_ASSET_PREFIX || undefined,

1. Upload only what changed. Assets are content-addressed; the manifest call returns which hashes the CDN already has, and only new files upload — into the site's own namespace.
2. Activate atomically. The new version becomes live in one step; there is no window where a page references assets that aren't there yet.

It never goes red because the CDN hiccuped

Anything missing or failing — no key, no network, a refused upload — degrades to a plain next build served from the origin. A deploy is never failed by its optimization.

Two footguns the flow already avoids

• Fonts: self-hosted font files served through a CDN prefix without CORS headers silently fall back — use link-based font loading with CDN builds.
• Canvas: CDN images drawn to a canvas without CORS taint it; anything that needs toDataURL (PDF export, cropping) should fetch bytes server-side instead.