A restaurant can survive a lot of things.
A slow day.
A broken printer.
A supplier arriving late.
But when the internet goes down during a busy dinner service, things can get chaotic very quickly.
Orders stop moving.
Kitchen tickets get delayed.
Bills become harder to process.
Tables become difficult to track.
And suddenly, the restaurant's most important operational system depends on something it doesn't control: the internet.
That problem is what led us to build OrderRestro.
OrderRestro is an open-source, offline-first restaurant management system designed specifically around restaurant operations — not a generic retail POS with a restaurant menu added on top.
The project is available on GitHub:
https://github.com/Raktim94/nodedr-restaurant-pos
It is built with:
Next.js
TypeScript
NestJS
PostgreSQL
Prisma
Socket.IO
Tailwind CSS
Docker
pnpm + Turborepo
And it is licensed under AGPL-3.0.
The problem with "everything in the cloud"
Cloud software is convenient.
There is no server to maintain.
Updates can happen centrally.
Data can be accessed remotely.
For many businesses, that's a great trade-off.
But restaurants have a different operational environment.
A restaurant might have:
A cashier at the POS
Servers using tablets
A kitchen display
A host managing reservations
A manager checking inventory
Multiple devices connected to the same local network
Most of these operations don't actually require the public internet.
They require the local network.
So we asked a simple question:
What if the restaurant's POS worked perfectly even when the internet disappeared?
That became one of the core architectural decisions behind OrderRestro.
Offline-first, not "offline as a fallback"
There is an important distinction here.
We didn't want to build a cloud application that happens to have a few offline features.
We wanted the restaurant to be able to run its core operation locally.
The default architecture is simple:
RESTAURANT LAN
┌─────────────────────────┐
│ Local Server │
│ │
│ Next.js + NestJS │
│ PostgreSQL │
│ Socket.IO │
└────────────┬────────────┘
│
┌──────────┼──────────┐
│ │ │
POS Kitchen Tablet
Screen Display / Phone
The restaurant can have one local machine running OrderRestro.
Every device connected to the restaurant's Wi-Fi or Ethernet network can access it.
If the WAN connection disappears, the restaurant's local system can continue operating.
Orders can still be created.
Bills can still be processed.
Kitchen tickets can still move.
Tables can still be managed.
Receipts can still be printed.
That is the fundamental idea behind the architecture.
Why build a restaurant-specific POS?
One of the decisions we made early was not to turn our existing retail POS into a restaurant POS.
Retail and restaurants look similar from a distance.
Both sell products.
Both need billing.
Both need inventory.
Both need customers.
But operationally they are very different.
A retail transaction might look like:
Scan product
↓
Add to cart
↓
Take payment
↓
Print receipt
A restaurant transaction is closer to:
Customer arrives
↓
Table assigned
↓
Order taken
↓
Modifiers selected
↓
Kitchen receives KOT
↓
Multiple kitchen stations prepare food
↓
Food served
↓
Additional orders
↓
Bill split / merge
↓
Payment
↓
Table becomes available
The system needs to understand the restaurant floor and kitchen.
That means tables, reservations, waitlists, kitchen stations, KOTs, modifiers, recipes, inventory, customer history and much more.
Trying to force all of that into a retail schema would eventually make both systems worse.
So OrderRestro became its own codebase.
What is actually inside OrderRestro?
The current project already covers a large portion of the restaurant operation.
- POS & Billing
The POS supports:
Dine-in orders
Takeaway
Delivery orders
Split bills
Merged bills
Discounts
Tips
Gift cards
Loyalty points
Multiple payment methods
Refunds
GST/VAT handling
Printable receipts
The goal is to keep the workflow fast.
A restaurant employee shouldn't have to navigate through five different screens just to close a table.
- Tables and Floor Management
Restaurants aren't just a list of transactions.
They have a physical floor.
OrderRestro provides a visual table layout where staff can see the current state of the restaurant.
For example:
┌────────┐ ┌────────┐ ┌────────┐
│ Table 1│ │ Table 2│ │ Table 3│
│ FREE │ │ SEATED │ │RESERVED│
└────────┘ └────────┘ └────────┘
┌────────┐ ┌────────┐ ┌────────┐
│ Table 4│ │ Table 5│ │ Table 6│
│ SEATED │ │ FREE │ │ WAITING│
└────────┘ └────────┘ └────────┘
Staff can manage seating, reservations and the waitlist from the same operational view.
- Kitchen Display System
This is one of the most important parts of a restaurant POS.
A traditional workflow often looks like:
POS
↓
Printed KOT
↓
Kitchen
↓
Someone loses the paper
↓
Customer waits
We wanted something more reliable.
OrderRestro sends kitchen tickets to a live Kitchen Display System.
NEW
↓
ACCEPTED
↓
PREPARING
↓
READY
Tickets can be routed to kitchen stations, and the display can show priority and elapsed-time information.
Because the system uses Socket.IO for realtime events, screens don't need to continuously poll the server waiting for changes.
The server can push the update when something actually happens.
- Menu and Combo Management
Restaurants need more than a product catalogue.
A menu item can have modifiers:
Burger
├── Size
│ ├── Regular
│ └── Large
│
├── Cheese
│ ├── None
│ └── Extra
│
└── Add-ons
├── Fries
└── Drink
OrderRestro supports categories, modifiers, combo meals and item availability.
This becomes especially useful during busy service when something sells out.
Instead of continuing to sell an unavailable item, staff can mark it unavailable.
- Inventory Based on Ingredients
Restaurant inventory is different from retail inventory.
A retail store might sell:
1 × Coca-Cola
1 × Notebook
1 × Shirt
A restaurant sells:
1 × Chicken Biryani
But internally that might consume:
Rice
Chicken
Oil
Spices
Onions
Yogurt
That's why OrderRestro uses recipe-based inventory.
The system can track ingredients rather than only finished dishes.
It also includes:
Recipe costing
Suppliers
Purchase orders
Goods receipts
Batch/lot tracking
Expiry tracking
Waste logging
Automatic stock deduction
Weighted-average costing
This gives restaurant owners a much better picture of where food costs are actually going.
- Customer Profiles and Loyalty
A restaurant's relationship with a customer shouldn't end when the bill is printed.
OrderRestro includes customer profiles with:
Visit history
Loyalty points
Feedback
Customer information
Gift cards
That creates the foundation for future CRM and marketing functionality.
The long-term goal is to connect the operational side of the restaurant with customer retention.
The architecture
The project is a monorepo built around a fairly conventional modern TypeScript stack.
nodedr-restaurant-pos/
│
├── apps/
│ ├── backend/
│ │ └── NestJS
│ │
│ └── web/
│ └── Next.js
│
├── packages/
│ └── types/
│ └── Shared Zod schemas
│
├── docs/
│
└── casaos/
The major pieces are:
Frontend
Next.js + TypeScript
The web application handles the POS, dashboards, kitchen display, tables, reservations, inventory and administration.
Backend
NestJS
The API provides the business logic and REST endpoints.
Database
PostgreSQL + Prisma
Restaurant data needs relational consistency.
Orders, bills, tables, customers, inventory, recipes and reservations all have relationships that benefit from a relational database.
Realtime
Socket.IO
Used for realtime restaurant events such as:
Kitchen tickets
Table updates
Order updates
QR-order status
Infrastructure
Docker Compose
The complete stack can run together as containers.
One of the most important rules: money belongs on the server
A POS is not a place where you want business-critical calculations happening only in the browser.
Prices, taxes, discounts and loyalty calculations need to be authoritative.
OrderRestro follows a server-authoritative model:
Client
│
│ "I want to buy this"
▼
Backend
│
├── Validate item
├── Calculate price
├── Calculate tax
├── Apply discount
├── Calculate loyalty
└── Save transaction
│
▼
PostgreSQL
The frontend is responsible for the interface.
The backend is responsible for deciding what the transaction actually means.
This matters even more when the system handles GST/VAT, refunds, loyalty balances and inventory.
Why PostgreSQL instead of SQLite?
An offline-first application doesn't necessarily mean "use SQLite."
We wanted the database architecture to support the operational complexity of a restaurant system.
PostgreSQL gives us:
Strong relational modelling
Transactions
Concurrent access
Mature indexing
A well-established ecosystem
A path toward larger deployments
And because PostgreSQL runs locally inside the Docker stack, using it doesn't require a cloud database.
The restaurant can still own the entire deployment.
Self-hosted means something different here
OrderRestro doesn't require the restaurant to send its operational data to our servers.
The default deployment can look like:
Restaurant
│
▼
Local Server
│
├── Application
├── PostgreSQL
└── Restaurant Data
The same application can also be deployed on a VPS when remote access is desirable.
There isn't a separate "cloud edition."
It's the same application.
That flexibility is intentional.
Open source changes the relationship
OrderRestro is released under the AGPL-3.0 license.
That means the project isn't simply:
"Here's a free demo. Pay us when you need the real thing."
The source is available.
You can inspect it.
You can self-host it.
You can modify it.
You can contribute to it.
And if you build a modified network service under the AGPL requirements, the license includes corresponding source-sharing obligations.
For a system that manages a business's operational data, being able to inspect what you're running can be valuable.
There is still a lot left to build
We don't want to pretend that a restaurant ERP/POS can be finished in a weekend.
The current system already covers core POS, kitchen, tables, reservations, CRM and inventory functionality.
But the roadmap is much larger.
Some of the areas planned for future phases include:
Deeper procurement
Delivery management
Full online ordering
Multi-branch management
Advanced analytics
Marketing campaigns
Accounting
Finance
Maintenance
Documents
More integrations
Advanced security features
The roadmap is intentionally public.
You can see the project and its current status here:
GitHub repository
Why not just use a SaaS POS?
That's a completely reasonable question.
For many restaurants, SaaS is the right answer.
You get support, hosting and a managed environment.
But there are businesses with different requirements.
For them, questions like these matter:
What happens if our internet goes down?
Where is our data stored?
Can we modify the system?
Can we run it on our own infrastructure?
Are we locked into a vendor?
Can we integrate it with our existing systems?
Do we really need another monthly subscription?
OrderRestro is an attempt to provide a different answer.
Not necessarily a better answer for everyone.
Just a different one.
The bigger idea
The interesting part of building restaurant software isn't the POS screen.
It's understanding the restaurant as a distributed system.
There are multiple actors:
Customer
│
▼
Server ────────► POS
│
▼
Kitchen
│
▼
Service
│
▼
Table
│
▼
Billing
│
▼
Customer CRM
At the same time:
Inventory ──► Recipes ──► Orders
▲ │
│ ▼
Purchasing ◄──────────── Sales
And:
Reservations
│
▼
Tables
│
▼
Orders
│
▼
Customers
A good restaurant system isn't just billing software.
It is the operational layer connecting all of these workflows.
That's the problem we're trying to solve.
Try it yourself
The easiest way to explore OrderRestro is through the project website:
https://orderrestro.nodedr.com/
The source code is available here:
https://github.com/Raktim94/nodedr-restaurant-pos
The project can be run with Docker, and the repository includes installation and development documentation.
For a quick-start deployment:
git clone https://github.com/Raktim94/nodedr-restaurant-pos.git
cd nodedr-restaurant-pos
./install.sh
Then open:
You can also run the stack on a local restaurant server, VPS, or compatible home-server environments.
We're building this in public
OrderRestro is still actively developing.
That means there are bugs.
There are unfinished modules.
There are architectural decisions that will evolve.
And there are probably things we've designed incorrectly.
That's also the reason we're building it in the open.
If you're interested in:
Open-source POS systems
Restaurant technology
Offline-first applications
Next.js
NestJS
PostgreSQL
Prisma
Socket.IO
Self-hosted software
Restaurant operations
Building vertical SaaS alternatives
take a look at the repository.
Issues, ideas and contributions are welcome.
Repository: https://github.com/Raktim94/nodedr-restaurant-pos
Product: https://orderrestro.nodedr.com/
Final thought
A restaurant shouldn't stop taking orders because its internet connection stopped working.
That sounds obvious.
But once you start designing the entire system around that principle, it changes almost everything:
How you deploy.
How realtime communication works.
Where data lives.
How the database is selected.
How the frontend talks to the backend.
How you think about backups.
And ultimately, how much control the restaurant has over its own software.
That's why we built OrderRestro as offline-first, self-hosted and open source.
Not because cloud software is bad.
Because sometimes the best cloud architecture is the one that still works when there is no cloud.
Top comments (0)