Introduction
This page explains how Litestore is built as a single Next.js app so you know what you are installing and changing.
Litestore is one Next.js 16 application. The same process serves both the storefront and the admin, and both read the same PostgreSQL database through Prisma.
This guide shows you how to install that codebase, host it, and extend it.
A storefront page is a React Server Component that queries Prisma directly. You don't run a separate backend service, a GraphQL gateway or a theme runtime.
The rest of the codebase is built around that decision. It is also why the pages in this guide talk about modules and scripts, and not about services you have to deploy and keep in sync.
What the repository contains
The app runs on Next.js 16 with the App Router and React 19. All of the code is written in TypeScript.
The app reaches PostgreSQL through Prisma 7. The schema in prisma/schema.prisma declares 70 models.
Litestore caches data with the Next.js tag cache. It only uses the tags defined in lib/cache.ts. Redis runs next to the cache and stores key-value data and rate limits.
The file events/types.ts declares 56 typed domain events. The code in services/webhooks/delivery.ts sends them to webhook subscribers.
You build storefront pages from the 10 block types listed in BLOCK_TYPES (lib/blocks/registry.ts). Each block type has a renderer in components/web/blocks/renderers/.
The admin's work queue knows 41 task kinds, defined in the AdminTaskData union (server/admin/tasks/queries.ts). Litestore derives each task from a query instead of storing it. Because there is no task table, a task can never fall out of date with the data it describes.
The repository includes 25 discipline checks in scripts/check-*.ts. You run them all with bun run verify.
The test suite has roughly 1,349 Vitest cases across 154 test files.
One database
Reports query the same rows that fulfilled the orders.
Because there is only one source of truth, nothing has to sync a transactional database with an analytics database. A dashboard figure and the row behind it always agree.
Extending by fork
You extend Litestore by changing your own copy of the code.
There is no versioned plugin API
Litestore does not ship a plugin sandbox, a hook registry, or a stable public extension surface. You change behaviour by editing the module that owns it, and you review every upstream change yourself when you merge.
This trade is deliberate. You can reach every layer of the app, and in return you pay the merge cost that a versioned plugin API would otherwise absorb.
Reading order
Where you start depends on what you are trying to decide.
If you are evaluating Litestore, start with the stack and the data model. Together they describe what you would run and what it stores.
If you are building on it, read blocks and events. Together they cover most of what teams want to change first.
If you are inheriting a codebase, read guarantees. That page lists the promises the rest of the code is allowed to rely on.