Introduction
Learn about Litestore's single-application architecture, where the storefront and admin are one Next.js app reading from Prisma.
Litestore is one Next.js 16 application that serves both the storefront and the admin from the same process, reading the same PostgreSQL database through Prisma.
A storefront page is a React Server Component that queries Prisma directly. There is no separate backend service, no GraphQL gateway, and no theme runtime to operate.
That is the decision the rest of the codebase is built around, and it is why the pages in this guide talk about modules and scripts rather than about services to deploy and keep in sync.
This guide covers installing, hosting, and extending that codebase.
What the repository contains
The framework layer is Next.js 16 on the App Router with React 19, and TypeScript throughout.
The database is PostgreSQL, reached through Prisma 7. prisma/schema.prisma declares 70 models.
Caching is the Next.js tag cache, used over a closed tag vocabulary defined in lib/cache.ts. Redis sits alongside it for key-value storage and rate limiting.
events/types.ts declares 56 typed domain events. services/webhooks/delivery.ts dispatches them to webhook subscribers.
Storefront pages are composed from 10 block types listed in BLOCK_TYPES (lib/blocks/registry.ts), each with a renderer in components/web/blocks/renderers/.
The admin's work queue is 41 task kinds in the AdminTaskData union (server/admin/tasks/queries.ts). Each kind is derived from a query rather than stored, so there is no task table to fall out of date with the data it describes.
The repository carries 25 scripts/check-*.ts discipline checks, run by bun run verify.
The test suite is roughly 1,349 Vitest cases across 154 test files.
One database
Reporting is a query against the same rows that fulfilled the orders.
With a single store of truth there is no sync between a transactional database and an analytics database, so a dashboard figure and the row behind it always agree.
Extending by fork
The extension points are seams inside 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.
That trade is deliberate: you get access to every layer, and you carry 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. Between them they describe what you would be running and what it stores.
If you are building on it, read blocks and events. Between them they cover most of what teams want to change first.
If you are inheriting a codebase, read guarantees — the list of promises the rest of the code is allowed to assume.