OrderRestro: Restaurant POS and operations

OrderRestro is a restaurant management system built to keep working when the internet does not. The database, the API and the web application run on one machine on the restaurant's own network.

It is a sibling of Nodedr POS, the retail point of sale. It reuses that project's patterns for authentication, receipts, ESC/POS printing and currency rounding, but lives in its own codebase because restaurant floor, kitchen and reservation operations are different enough from retail billing that one schema serving both would have compromised both.

Restaurants split billing, table status, kitchen tickets and reservations across a till, a printer and a separate kitchen screen, usually on a subscription that stops working the moment the connection drops.

Waiters taking orders, kitchen staff reading tickets, cashiers billing, managers configuring menus and permissions, and guests who order from a table QR code.

An order is taken with modifiers, routed to the kitchen display by station, and its status changes push back to the floor. Tables, reservations with a waitlist, QR table ordering, loyalty points, gift cards and combo meals all hang off the same order model.

Three kinds of screen need the same live state: the till, the kitchen display and the table map. Polling would have been simple, but a kitchen ticket that appears twenty seconds late is a failure the user can feel.

A pnpm and Turborepo monorepo with a NestJS backend and a Next.js App Router frontend. NestJS was the one deliberate departure from the plain Express used in Nodedr POS: twenty product domains that must be independently addable and permission-gated need real module boundaries and dependency injection, and those would otherwise be hand-built.

Realtime uses a Socket.IO gateway with a namespace per concern for the kitchen, tables and orders.

PostgreSQL through Prisma is the primary target. The original brief asked for SQLite for single-location installs. I chose PostgreSQL instead and wrote down why in the architecture document, because two database dialects for one product doubles the migration and testing surface.

Each domain, such as menu, inventory and kitchen display, is a self-contained module with its own controllers, services and validation. A documented REST API, webhooks and an MCP server expose the system to other software.

Next.js with Tailwind, TanStack Query for optimistic updates, TanStack Table for large lists and a drag-and-drop floor designer. The point-of-sale screen is built for touch and speed. A thin Windows client wraps the web app for tills that are Windows machines.

Every action is gated by a granular, individually toggleable permission, never a hard-coded role check. Sessions use an httpOnly cookie with PIN quick-switch for fast staff handoff on a shared till. TOTP is optional per user. All price, tax, discount and loyalty arithmetic runs on the server and the client is never trusted for money.

Three containers: PostgreSQL, API and web. The same compose file runs on a restaurant's LAN server, on a VPS, behind a tunnel, or as a CasaOS app. I documented a trap in the tunnel case: the session cookie must be marked Secure once traffic arrives over HTTPS, but a Secure cookie is silently dropped on a plain HTTP origin, which makes every login appear to succeed and then return Unauthorized.

The reliability target is that order-taking, billing, the kitchen display and printing continue with the WAN cable unplugged. That is a design constraint applied to every module, not a configuration option.

Offline-first means the restaurant owns a server. That removes subscription dependency and also moves backups, updates and hardware failure onto the operator, which is a real cost for a small business.

Architecture, backend, web application, the permission model, deployment packaging and documentation. A recent round of work added the REST API reference, webhooks and an MCP tool surface.

Reusing a proven pattern is worth more than reusing the code. I kept the lessons of the retail POS and rebuilt the domain model for a different business.