Raktim94/nodedr-restaurant-pos
Productivity & UtilitiesA self-hosted restaurant POS that keeps billing, kitchen tickets and printing running on a local server when the internet drops.
Worth a look if you run a small restaurant and want billing, tables and kitchen display on your own hardware; read the roadmap before promising it to staff, because several modules are still marked planned.
The problem
A restaurant's evening service depends on order-taking, bill printing and kitchen tickets. With a typical cloud POS, an ISP outage turns all three into improvisation: paper chits, a calculator and a phone call to the kitchen. OrderRestro moves the whole stack—Postgres, API and web app—onto one machine on the restaurant's LAN, so tills and kitchen screens reach it at the server's local address and no internet connection is needed once it is running. The workflow change is structural rather than cosmetic: taking an order no longer round-trips through the internet, and printing continues without a WAN link.
What's different
The project is built around dine-in service rather than treating a restaurant as a retail store with tables added. It includes a visual floor plan, kitchen display with station routing, QR table ordering, reservations and waitlists, and UPI QR checkout for India, where the till and customer-facing screen show a QR for the exact bill amount with no payment gateway fee. Staff attendance, payroll and tip pools are part of the same system, which reduces the number of separate accounts and exports a manager has to stitch together. Multi-region tax is configurable, including India GST, US sales tax and EU VAT.
The trade-off is the size of the claim. The README lists a 20-module scope and explicitly labels status: core POS, tables, KDS, menu, inventory, procurement, CRM and payroll are marked done, while split billing and split tender are not. Native payment-gateway checkout, delivery-platform and accounting-software connectors, weighing scales, label printers, a SQLite edition and native installers are listed as unbuilt. So the system is more cohesive than a collection of scripts, but it is not a drop-in replacement for every function a mature commercial POS offers today.
The deployment model is also part of the design. One docker compose up on a local machine is the recommended path, with a CasaOS/ZimaOS one-click option. Windows tills can use a thin WinForms + WebView2 client that points at the server rather than opening a browser tab. Because everything runs on one server, that machine and the LAN become the continuity point staff must understand; the README does not document a failover setup.
Who should try it
This fits an independent restaurant, café or small chain that already has a server or mini-PC it can leave on-site and someone comfortable running Docker and reading logs. The offline-first and UPI-QR features are especially relevant in India, where paying a gateway fee per transaction and losing billing during an outage are practical recurring costs.
It is a poor fit for a venue that needs split tender or split billing now, weighs products at the counter, or expects native delivery-platform and accounting integrations out of the box—the roadmap says those parts are planned. A single-till operation with no technical help on hand may also find the local-server model burdensome compared with a hosted POS, even though the self-hosting requirement can be satisfied by a one-click CasaOS app.
Requirements and limitations
You need Docker with Compose v2 and Node 22 or newer per the README badges; the install script itself handles the build. The web UI is at port 1995 on the host, and the backend API and Swagger docs are only reachable through the web app's /api proxy, so external integrations cannot simply hit the API directly. Windows installs should be run from WSL2 or Git Bash, since the setup script is a shell script. Afterwards, upgrades mean re-running the installer after a git pull, which rebuilds images and restarts the stack; the server, Postgres volume and LAN address become things you maintain, not the vendor.
The AGPL-3.0 license matters if you modify the code and offer it to others as a network service: those users must be able to get your modified source. For a restaurant running it in-house, that is unlikely to bite, but it affects anyone planning to build a hosted offering on top. Reports export to Excel, PDF and CSV, and scheduled email uses your own SMTP server, so that optional feature does depend on internet access.
HotRepo's take
The project first appears in the tracked daily board on 2026-10-27, with 174 stars and +35 that day—one observation at 85 days old. That is a snapshot, not a trend; persistence cannot be judged from a single dated board entry. Before committing, check the roadmap against the modules your service actually uses, especially split billing and delivery integrations, and confirm that your floor's printing and station-routing setup is covered.
Written by AI from the project's README, updated October 27, 2026. The project's own docs are the source of truth.