Walkthrough

From file to browser

A Markdown file is committed, and later a visitor reads it as a page. This Walkthrough follows one file from its folder to the visitor's screen: through the manifest that names its table, the build that packs the table into a dump, the server that loads the dump and renders the page, and the payload the browser reuses on the next click. Only a query no payload answers (on a route the server doesn't cache, or outside useAsyncData) makes the browser load the dump into a database of its own.

A file lands in a Space's folder

A starts as a Markdown or YAML file in its Tenant's folder under layers/, at content/<space>/<collection>/, merged to main like any other change. The folders name its , its and its ; nothing else says where it belongs.

The manifest names its table

The Tenant's lists its Spaces and Collections. Each time Nuxt Content loads content.config.ts, expand() turns every manifest into one collection per Tenant, Space and Collection, each pointed at its own folder and named by a key such as blog_david_pages. That key is the name of the file's table.

LessonContent collections
LessonMulti-tenant isolation

The build parses it into SQLite and a dump

pnpm build runs nuxt build, and Nuxt Content parses every file a collection matches. It inserts each Collection's rows into a table of its own in an SQLite database, and packs each table's SQL dump into the server it builds. The build writes no HTML: every page is rendered when someone asks for it. A change goes live follows that build onto the live server.

LessonContent database
LessonContent validation

A request renders it, or the cache answers

A Caddy proxy passes the visitor's request to , Nuxt's server, which first checks its page cache: a copy rendered moments ago goes back as it is. On a miss, Nuxt picks the page file that matches the address, and its useSpace turns the address into the keys of one Space's Collections, or a 404. The page's useAsyncData then calls queryCollection with its key, on the server.

The first query restores the table from the dump

The first query for a Collection since the server started compares the checksum stored with its table to the build's. Where they differ, Nuxt Content runs that Collection's dump into the server's SQLite database before it answers; where they match, it answers from the table as it is. Either way the query reads only its key's table.

LessonContent database
LessonMulti-tenant isolation

The browser hydrates, then navigates by payload

Vue renders the page to HTML with the useAsyncData result inside, and the browser shows it, then takes the page over without fetching that data again. When the pointer rests on a link, a finger touches it or the keyboard focuses it, the browser fetches that route's code and its _payload.json, and the click builds the next page from them with no query. A route the server doesn't cache has no payload, and neither has a query outside useAsyncData, such as a search run as the visitor types. Either kind of query runs in an SQLite database in the browser, which first downloads a WebAssembly runtime and the Collection's dump.

Where next

Last updated 1 Nov 2026 · Latest source on GitHub ↗