Self-hosted restaurant POS with a kitchen display that keeps working offline: OrderRestro

Short answer: OrderRestro is a restaurant management system whose database, API and web application all run on one machine inside the restaurant. Order-taking, billing, the kitchen display and printing keep working when the internet is unplugged. It is open source under AGPL-3.0 and I built it as lead developer.

Why does a restaurant need offline-first software?

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 when the connection drops. During service, a kitchen ticket that arrives twenty seconds late is a failure everyone in the room can feel.

What does OrderRestro do?

• Takes orders with modifiers and routes them to the kitchen display by station.
• Pushes status changes back to the floor in real time.
• Manages tables with a drag-and-drop floor designer, plus reservations with a waitlist.
• Supports QR table ordering, loyalty points, gift cards and combo meals on the same order model.
• Exposes a documented REST API, webhooks and an MCP server so other software can work with it.

How do the till, kitchen and table map stay in sync?

Three kinds of screen need the same live state. Polling would have been simple, but it is the wrong trade for a kitchen. OrderRestro uses a Socket.IO gateway with a namespace per concern for the kitchen, tables and orders, so a change appears everywhere at once.

What is the architecture?

A pnpm and Turborepo monorepo with a NestJS backend and a Next.js App Router frontend, using PostgreSQL through Prisma. NestJS was the one deliberate departure from the plain Express used in NodeDR POS: about twenty product domains that must be independently addable and permission-gated need real module boundaries and dependency injection.

I chose PostgreSQL over the SQLite the original brief suggested, and recorded why: two database dialects in one product double the migration and testing surface.

How is money kept correct?

All price, tax, discount and loyalty arithmetic runs on the server and the client is never trusted for money. Every action is gated by a granular, individually toggleable permission instead of a hard-coded role check. Sessions use an httpOnly cookie with PIN quick-switch for fast staff handoff on a shared till, and TOTP is optional per user. The GST-inclusive pricing lessons from the retail product are covered in Calculating GST-inclusive MRP in a POS.

How is it deployed?

Three containers: PostgreSQL, API and web. The same compose file runs on a restaurant LAN server, a VPS, behind a tunnel or as a CasaOS app. One trap I documented: behind HTTPS the session cookie must be marked Secure, but a Secure cookie is silently dropped on a plain HTTP origin, which makes every login look successful and then return Unauthorized.

What is the catch?

Offline-first means the restaurant owns a server. That removes the subscription dependency and also moves backups, updates and hardware failure onto the operator, which is a real cost for a small business. The longer discussion is in Offline-first restaurant software, and the full OrderRestro case study has the rest.