FUNCTIONS / @SPFN/PAGES-NEXT — NEXT.JS FOR THE SITE MODEL

One route,
whole site.

The Next.js side of @spfn/pages: a validated site model becomes a deployable site through a single optional catch-all route. Self-deploy carries a ~4-file scaffold and runs anywhere Next.js or static output runs; SPFN hosting reuses the same layouts and helpers, resolving the tenant per request.

Read the reference Get started $ spfn-pages sync && next build
01
The premise

One package.
Two ways to ship.

The whole route surface is app/[[...slug]]/page.tsxcreateSitePages returns generateStaticParams, generateMetadata, and the page component, and the content repo needs nothing more than that ~4-file scaffold. Deploy it to Vercel, Cloudflare Pages, or your own server; static export (output: 'export') is fully supported. The multi-tenant hosted edge runs the same layouts and helpers with no scaffold in the repo at all — registering the repo link is enough.

site model
createSitePages
app/[[...slug]]
deployed site
FIG 01 — SELF-DEPLOY OR SPFN HOSTING · SAME LAYOUTS, SAME HELPERS
02
Core technique

The build that cleans up
after itself.

Two things in the site model can't be rendered by Next.js — raw HTML escape-hatch pages and site/public/ assets — so spfn-pages sync materializes them into public/ before the build and records every output in public/.spfn-pages-sync.json. The next run deletes recorded outputs it no longer produces — a moved landing, a removed asset — so stale pages never ghost into the static export, while files sync never wrote are left alone. The content itself comes from FsContentSource('.'), which reads the checked-out repo directly: builds see exactly the commit they run on, no GitHub API calls, no rate limits.

materialize to public/
record every output
next run compares
stale outputs deleted
FIG 02 — MANIFEST: public/.spfn-pages-sync.json · HAND-PLACED FILES UNTOUCHED · NO GITHUB API AT BUILD
03
What's inside

The rendering layer,
already assembled.

Ship the site.