Resto is a complete restaurant operating system in one Laravel application. One install runs the till, the kitchen screens, the floor plan, the waiter’s phone, the stockroom, the purchase ledger, the payroll, the double-entry books, the online store and the reports that tie them all together — for one restaurant or for a group of branches sharing a single database.

Resto — Restaurant Management System Features

It is not a POS with some reports bolted on. A burger sold at the till leaves the walk-in as a bun, 150 g of beef and 20 g of cheese, lands as a journal in the general ledger, awards points to the customer who bought it, and shows up in the food-cost report as a margin — without anybody typing anything twice.

Everything is self-hosted. No SaaS subscription, no per-terminal licence, no monthly fee. Install it once on your own server or on ordinary shared hosting, and it is yours.

Why buyers pick Resto

It covers the whole restaurant, not one slice of it. POS, KDS, floor, delivery, inventory, purchasing, HR, accounting and e-commerce ship in the same box, already wired together.
It runs on shared hosting. No Node daemon, no Redis, no websocket server, no queue worker required. If it can run Laravel and MySQL, it can run Resto.
It keeps selling when the internet drops. The POS terminal queues orders locally and syncs them the moment the connection returns.
The numbers are auditable. Stock, loyalty points and gift-card balances are ledgers, not editable columns. Refunds are separate documents; the original sale is never rewritten.
It installs in a browser. A five-step wizard checks the server, writes .env, migrates the schema and creates the owner account. No SSH, no editing config files.
8 languages out of the box, including full RTL Arabic — plus a built-in translation editor so you can add your own without touching a file.

Feature list

1. Web installer

A guided, five-step first-run wizard:

Requirements check — PHP version, extensions, directory permissions, all shown pass/fail before you go any further.
Application settings — site name, URL, timezone.
Application key generated for you.
Database — credentials with a Test connection button that verifies before it commits.
Administrator account — the first owner.
Review & install — migrates the schema, seeds the restaurant, writes the install marker.

Answers are held in the session until the final confirmation, so an abandoned wizard can never leave you with a rewritten .env pointing at an un-migrated database. Once installed, the installer seals itself off.

2. Dashboard

The first screen of the day, built to answer three questions in order:

How is today going against yesterday — takings, orders, average check, covers.
Is anything about to become a problem — low stock, unpaid tables, late deliveries, pending reservations, unmoderated feedback.
Where is the month heading — a trend chart over trading history with a moving average drawn over it.

Branch-scoped, so a manager sees their outlet and an owner sees the one they select. Every aggregate is an indexed group-by, so it stays fast as history grows.

3. POS terminal

The till, built for a touchscreen and a busy service.

Three-state flow — pick a terminal, open a shift with a declared float, then sell. Each is its own screen, so a cashier is never looking at a grid they cannot ring up on.
Fast item grid — categories, featured items, search-or-scan, variants and sizes inline.
Modifiers with rules — required groups, min/max choices, priced options, free allowances. The terminal enforces them before the order can be sent.
Combos — “choose a main, choose a drink” groups resolved at the till.
Order types — dine-in, takeaway, delivery, drive-thru and room service, each able to carry its own prices and taxes.
Park & recall — hold an order under a name you’ll recognise (“Blue jacket, Table 5”) and pick it back up later.
Send to kitchen without payment — fire the ticket, take the money at the end.
Split & partial payments — multiple tenders on one bill, with the balance still due shown after each.
Payment methods — cash (with change calculation and cash-drawer control), card with reference/auth code, wallet, gift card, customer account credit, and online.
Tips — preset percentages or a custom amount, tracked separately as money owed to staff.
Discounts and voids — reason-coded, and optionally locked behind a manager PIN.
Line-based refunds — refund half a table’s order; each line remembers how much has already been given back, so the same dish can never be refunded twice. The original sale is never edited.
Offline mode — a service worker keeps the terminal loadable with no connection, orders queue locally, and a badge shows what’s waiting. They sync automatically when the line comes back, and any order that needs attention says so.
Receipt printing through the browser — thermal, laser or PDF, no driver and no vendor library.
Staff clock-in at the terminal by PIN — the same PIN used for manager overrides, so it’s one number per person.

4. Shifts & cash-up

Open a shift with a declared opening float.
Cash movements during the shift — paid-outs, drops, pick-ups, all reason-coded.
Close the shift by counting the drawer: expected versus counted, with the variance calculated for you.
Shift report — takings by payment method, discounts, voids, refunds, tips, per terminal and per person.
Shift log in the back office for every cash-up ever taken.

5. Orders

Full order list across every channel — POS, waiter app, online store, API — with filters by status, type, channel, branch and date.
Order lifecycle: held, open, sent, ready, served, completed, plus cancelled.
Line-level detail: modifiers, variants, discounts, taxes, the person who rang it up.
Payment history, refund history, kitchen ticket history per order.
Void and refund from the back office with reason codes.
Configurable order numbering — prefix, and a daily reset.
A configurable business-day start hour, so a 2 a.m. sale lands on the right trading day.

6. Tables & floor plan

Multiple floors — terrace, main room, mezzanine.
Drag-and-drop plan editor — positions saved in grid units, not pixels, so the same layout renders correctly on a phone, a tablet and a wall-mounted screen.
Live floor map — who is sitting where, for how long, and what they owe. The same screen serves the cashier at the till and the waiter on a phone.
Table sessions — open a table, add courses, move guests to another table, merge two parties onto one session, and split a table back off a merged party without disturbing the orders already on it.
Table QR codes — a printable sheet of cards, one per table. Codes are stable across reprints, so old cards keep working. Guests scan to see the menu and order.

7. Kitchen Display System (KDS)

Station screens — grill, fryer, cold, pass; each screen is bolted to one section and remembers its choice.
Live ticket board with item, modifiers, table, order type and elapsed time.
SLA colouring — tickets age from green through amber to red against a configurable target, so the pass can see what’s late at a glance.
Bump, recall and mark-ready per item or per ticket.
Polling, not websockets — deliberately. The poll returns a fingerprint first and the full board only when something has actually changed, so it is cheap on shared hosting and does not silently die at 3 a.m.
Routing rules send each item to the right station automatically.

8. Waiter app

A phone-sized view of the same live floor.
Installable as a PWA — sits on the home screen and opens in one tap during service.
The waiter’s own feed: their tables, which are waiting on food, and which dishes are ready to run.
Take orders, fire courses, request the bill, all from the floor.

9. Reservations & waitlist

The book, one day at a time — the way a host actually reads it.
Reservation statuses: pending, confirmed, seated, completed, cancelled, no-show.
Configurable slot length, turn time and auto-confirm.
Table assignment, party size, guest notes, contact details.
Waitlist for walk-ins on a full night.
Online reservation requests from the public site feed straight into the book.

Categories with sort order, images and visibility.
Menu items with images, descriptions, dietary and allergen notes, prep time, station routing, tax group and featured flag.
Variants — sizes, portions and versions of a dish, each with its own price and its own recipe.
Modifier groups & modifiers — required or optional, min/max selections, free allowances, priced extras, reusable across items.
Combos — meal deals built from choice groups (“choose a main”, “choose a drink”), with each group edited on the combo’s own page.
Price books — a lunch special, delivery pricing, a branch that charges more, a channel that charges less. Books are matched on branch, channel, order type and the clock; the highest-priority match wins, and any item not listed falls back to the default book. That’s what keeps a lunch-special book three rows long instead of a full copy of the menu.
Availability — the 86 board — what is off the menu right now, per branch. Sold-out items simply do not appear on the terminal, so a waiter can’t promise a dish that ran out an hour ago.

11. Inventory

Ingredients with categories, units, cost, reorder level and supplier links.
Units of measure with conversions — buy in cases, count in kilos, use in grams.
Recipes — per menu item and per variant, with sub-recipes handled properly. A pasta uses tomato sauce; the sauce has its own recipe and its own stock. Two rules keep it sane: a prep that is stocked is consumed as itself (selling the pasta takes sauce out of the walk-in, not tomatoes out of the dry store — exploding all the way down would deduct the tomatoes twice), while costing does explode all the way down, so a rise in the price of tomatoes reaches the food cost of every pasta on the menu without anyone re-entering anything. Recursion is depth-limited and cycle-guarded, so a sauce that somehow lists itself fails loudly rather than hanging a sale.
Automatic stock deduction on sale. Idempotent by design: a replayed offline order, a retried payment or a reopened bill can never take the same food out twice, because the ledger is checked rather than a flag trusted. Reversible: a void or a refund with the food coming back puts the stock back as its own movement, so the stock card still shows it went out and came back.
Stock movements ledger — opening, purchase, sale, void return, waste, adjustment, transfer in, transfer out, production in, production out and count. Nothing is ever deleted.
Stock levels per branch, with valuation.
Batches and expiry tracking.
Wastage recording with reason codes, costed.
Stocktake — a count sheet built for someone standing in a walk-in with a tablet. It saves as you go and never demands the whole sheet at once, so a shelf is never lost to a sleeping screen. Variance and shrinkage calculated on posting.
Transfers between branches, with in and out movements on both sides.

12. Purchasing

Suppliers with contact details, payment terms, and the ingredients they supply at their prices.
Purchase orders — raise, approve, send, track.
Goods receipts — receive against a PO in full or in part, record short deliveries and price differences, and post the stock in at its real landed cost.
Supplier payments and outstanding balances.
Document numbering that doesn’t collide.

13. Customers & marketing

Customer records — contact details, multiple saved addresses, order history, lifetime value, notes.
Customer groups for segmenting and for group pricing.
Loyalty points — earned on the net value of an order, not the gross, so you aren’t giving away a share of money you’re holding for the tax authority. A real ledger with a cached balance, idempotent per order, so a replayed payment never pays out twice.
Store credit and gift cards — both ledgers, both redeemable at the till and online, neither with a balance anyone can type in directly.
Coupons — percent off, fixed amount off, free item, free delivery. Rules for minimum spend, date window, usage cap, per-customer cap, channel and branch. Validation returns a reason, not a boolean: “that code needs 25” is the message that makes a guest order more, where “that code is not valid” is the one that makes them argue with a cashier.
Feedback & reviews — nothing publishes by default. The screen exists to find Saturday’s two-star review before the customer puts it somewhere public instead.

14. Delivery

Dispatch board — what’s waiting, who’s out, and how late it is. Polls itself so a new order appears without a refresh.
Riders — assign, track, and see the load per person.
Delivery statuses: pending, assigned, picked up, delivered, failed.
Delivery zones, defined two ways because that is how different places think about it: a list of postcodes, or a radius in km from the branch. The radius check is a straight haversine calculation — no mapping service, no API key and no per-request cost. Each zone carries its own delivery fee, minimum order, free-over threshold and ETA, so an out-of-range address is refused at checkout instead of at the door.
Delivery fees priced into the order and posted to their own income account.

15. Online store & QR ordering

A full public-facing ordering site, included:

Server-rendered menu — deliberately, not a JSON app. A QR menu Google cannot read is a marketing asset thrown away, and a hungry customer should not wait on a bundle.
Item pages with images, descriptions, variants and modifiers.
Cart and checkout — dine-in (via table QR), collection or delivery, with address capture and zone validation.
Stripe Checkout for card payments. The card number never touches your server, which keeps your PCI obligation to the smallest questionnaire there is. Cash on delivery and pay-at-counter also supported.
Order tracking page — an unguessable link the guest already has in their browser history, so someone who never made an account can still watch their food.
Optional customer accounts — saved addresses, order history, loyalty balance.
Storefront controls — opening hours, whether it’s accepting orders at all, and a panic button for a Friday night.
Table QR codes for scan-to-order at the table.
Fully branded: your logo, your colours, your language.

16. Staff & HR

Staff records — role, branch, pay rate, weekly hours, overtime multiplier, commission percent, leave entitlement, tip-share flag, hire and leave dates.
8 built-in roles — Owner, Manager, Cashier, Waiter, Chef, Storekeeper, Accountant, Rider — each with sensible default permissions.
14 permission sections — POS, orders, tables, kitchen, menu, inventory, purchasing, customers, reservations, delivery, staff, accounting, reports, settings — overridable per user. Hiding a menu link is presentation; the middleware is the actual guard, and the same permission gates the API and the global search.
Attendance — clock in and out at the terminal by PIN, with timesheets a manager can correct.
Leave requests with approval and balances.
Payroll — draft runs you can rebuild as often as you like (somebody always forgets to clock out), then approve to freeze the payslips, because the point of a payroll record is that it says what was actually paid. Hours, overtime, commission, tips and named deduction lines. It deliberately does not calculate payroll tax — that is jurisdiction-specific, changes yearly, and getting it subtly wrong is worse than not offering it; deductions are entered as named lines your accountant supplies.
Payslips per employee per run.
Activity log — who did what, when, from where.

17. Accounting

Real double-entry books, posted automatically from operations:

Chart of accounts — seeded, editable, with account types and ledger slugs.
Automatic posting — a sale posts cash/card/receivables and discounts against sales, delivery income, service income, tax owed and tips owed, plus the food leaving the kitchen as cost of sales. Goods receipts, expenses, wastage and pay runs post themselves too. Nothing is typed twice, and every posting is idempotent — posting the same order again is a no-op. Posting runs after the operational record exists, so if the books are wrong the sale still happened.
Manual journals with a line editor that won’t let you save an unbalanced entry.
Ledger view per account with running balance and drill-through to the source document.
Trial balance.
Profit & loss for any period.
Balance sheet.
Period close — lock a month so nobody posts into a filed period.
Expenses with categories, receipts, recoverable tax and supplier links.

18. Reports

Four screens rather than forty. Each answers a question an owner actually asks, and each exports the table it’s showing.

Sales reports — gross takings, net sales, average check, covers, orders; sales day by day and by hour of day; by channel, by order type, by cashier, by payment method; discounts given, voids and refunds with their reason codes, and who gave away what.

Food cost & menu engineering — cost of food sold, gross margin, every dish sold with its cost, revenue, margin and share; by category; modifier attach rates; and a full menu-engineering matrix classifying dishes as Stars (popular and profitable — protect these), Ploughhorses (popular but thin — reprice or re-cost), Puzzles (profitable but ignored — move them up the menu) and Dogs (neither — consider dropping them).

Inventory reports — stock on hand and valuation by category, consumption, what was used versus what was sold, usage variance and unexplained shrinkage after waste, wastage by reason, supplier spend, purchase price movement, and everything below its reorder level.

Financial reports — profit and loss, revenue, cost of sales, gross and net profit and margin; expenses; tax return with tax on sales, tax on purchases, tax on expenses, reclaimable and payable; tips taken; discounts by person; and every cash-up with its expected, counted and variance figures.

Every report runs on a period picker and exports to CSV.

19. Multi-branch

One install runs one business; a business can run several branches off the same database — each with its own stock, tables, terminals, staff, prices, taxes, opening hours and reports. Stock transfers move goods between them. Reports roll up or scope down. A single-site restaurant never opens this screen again after the installer.

20. Taxes & charges

Built for real-world tax, not a single percentage field:

Tax groups with multiple taxes in an ordered stack.
Compound taxes — charged on the running total including the taxes ordered before them (Quebec, parts of India), so order matters and the effective rate isn’t the sum of the rates.
Tax-inclusive pricing — where the menu price is the gross and the net is worked backwards out of it, as most of Europe, the Gulf and Asia price. Solved exactly rather than approximated, including the awkward case of a compound percentage sitting after a fixed levy. Get this direction wrong and every VAT return is wrong while every receipt still looks right — which is why it survives to production so often elsewhere.
Fixed and percentage taxes in the same group.
Service charge — percentage, and taxable or not.
Cash rounding to any increment, for currencies without small coins.
Per-item, per-branch and per-order-type tax assignment.
Tax number printed on receipts and shown on the tax return.

21. Settings

General — site name, logo, favicon, timezone, default language, dashboard footer text, and whether the theme customizer button is shown.
Money — currency code, symbol, position, decimals, tax-inclusive pricing, tax number, service charge, cash rounding.
Orders — order number prefix and daily reset, business-day start hour, tips on/off, deduct inventory on sale, KDS default SLA, manager PIN required for voids and for discounts.
Reservations — slot length, turn time, auto-confirm.
Branches — outlets, addresses, contact, opening hours, storefront settings.
Taxes & charges — taxes, tax groups, service charge.
Kitchen stations — screens and routing.
Printers & receipts — receipt width, header and footer text, logo, which documents auto-print and when, with a live preview and a test print using a real document rather than a guess. No driver needed: printing goes through the browser, so anything the device can already see works.
Payment gateways — till methods (enable, rename, reorder, set which open the drawer) and Stripe keys for online payments, with a validate-and-test flow before it goes live.
Notifications — SMTP settings, and which emails go out to whom: order confirmations, status updates, reservation confirmations, low-stock alerts, daily summary. Nothing on the list is aspirational.
API tokens, Languages and Backup & update — see below.

22. REST API

Versioned /api/v1 with token authentication.
Endpoints: ping, menu, orders (list, create, show, update status), stock, ingredients, customers, reservations and a summary.
Scoped tokens using the same permission vocabulary as the back office — a token can only ever narrow what its owner may do, so revoking a manager’s access shuts their integrations out too.
Rate limited per token, not per IP, so several integrations behind one office NAT don’t throttle each other.
Token plaintext is shown once and never again — inconvenient exactly once per token, and the difference between a leak that costs one integration and one that costs all of them.
Ideal for delivery aggregators, custom mobile apps, BI tools and accounting exports.

23. Languages & RTL

8 languages included: English, French, Spanish, German, Portuguese, Turkish, Hindi and Arabic (full RTL).
A dedicated RTL stylesheet bundle, loaded automatically for right-to-left locales — the admin panel, the POS and the public store all mirror properly.
Language switcher in both the back office and the storefront; the admin chooses which languages appear.
Built-in translation editor. Resto ships with no language file as its source of truth — every string is its own English text in the code, so an untranslated product reads as English rather than as a placeholder key, and a missing translation degrades to readable English. The editor scans the source, lists every string, lets you type the other side, and writes one JSON file per locale. You never need a template, and adding a language never requires a developer.

24. Theming

Light, dark and system themes across the admin, the POS and the storefront, with no flash on load.
Primary colour presets plus a custom hex picker.
Corner radius: sharp, regular or rounded.
Your logo and favicon throughout.
Built on Tabler, so it is clean, dense and responsive from a phone up to a wall screen.

25. Backup, updates & maintenance

One-click database backup, written in pure PHP rather than shelling out to mysqldump — plenty of shared hosts disable exec(), and a backup feature that works on the developer’s laptop and nowhere else is worse than none, because the buyer only finds out on the day they need it. The output is plain SQL any MySQL client will restore, so your backup is never hostage to this product.
Download, list and delete backups from the panel.
Version display and a straight account of what updating involves — a file copy and a migration.
Global search in the header: an order number, a customer’s phone, a dish, an ingredient, a colleague, or a back-office page by name, so “payroll” gets you to payroll without learning the sidebar. Every group is gated by the permission that guards its pages.
Demo mode with a reset button, for anyone showing the product off.
Rich demo data seeders — a fully populated restaurant with menu, floor, stock, purchases, sales history, staff, HR and accounting, so a fresh install is something you can explore rather than an empty shell.

Technical

Framework — Laravel 13
PHP — 8.3+
Database — MySQL / MariaDB
UI — Tabler 1.4, Tabler Icons
JavaScript — Alpine.js 3, Chart.js 4, SweetAlert2 — no heavy SPA framework
Build — Vite 8 (compiled assets ship with the package — no build step required to deploy)
Offline — service worker for the POS terminal
Payments — Stripe Checkout (written against the HTTP API, no SDK dependency tree)
QR — Bacon QR Code
Architecture — service-layer domain code: ordering, pricing, tax, inventory, kitchen, POS, HR, accounting, reporting and channels each in their own namespace
Tests — feature and unit test suite covering the money-critical paths

Deliberately not required: Node daemons, Redis, websocket servers, queue workers, exec() access, or a vendor printer driver. Resto is built to run where restaurant buyers actually host — cheap, shared, and unattended.

Server requirements

PHP 8.3 or higher
MySQL 5.7+ / MariaDB 10.3+
Apache or Nginx with URL rewriting
Standard Laravel PHP extensions (BCMath, Ctype, cURL, DOM, Fileinfo, JSON, Mbstring, OpenSSL, PCRE, PDO, Tokenizer, XML, GD)
Writable storage/ and bootstrap/cache/
SSL certificate recommended (required for Stripe)

The installer checks every one of these and tells you which are missing before you start.

What’s included

Full source code, unencrypted — and documented throughout
Compiled front-end assets, ready to deploy
Browser-based installer
Demo data seeders
8 language files
Documentation
Free lifetime updates
6 months of included support

Ideal for

Restaurants, cafés, pizzerias, fast food and QSR, food trucks, cloud and dark kitchens, bakeries, patisseries, dessert and ice-cream shops, coffee shops, canteens and staff catering, franchise and multi-branch groups, hotel restaurants and room service, and developers building a restaurant product for a client.

Resto — one install, the whole restaurant.

Resto — Restaurant Management System, POS, KDS & Online Ordering