Open-source restaurant POS: options and a go-live checklist

An open-source restaurant POS can give your team control over the software, but you still need someone to run it. Choose the system only after you have named who will maintain it, checked the license for the exact version and add-ons, and tested your menu, payment hardware and kitchen tickets together.

This guide compares three projects' published scope and gives you a proposed go-live checklist. For a broader comparison of commercial systems, use the restaurant POS buying guide. For subscription and processing examples, see restaurant POS costs.

Which open-source POS projects should a restaurant inspect?

OSPOS: a register with stock records and restaurant tables

Open Source Point of Sale (OSPOS) lists sales, inventory, receipts, multiuser permissions and restaurant tables. It runs on PHP with MySQL or MariaDB. The project describes its license as MIT with an added requirement to keep its footer visible and unchanged. Read those terms before changing the interface or hiring someone to rebrand it.

Its feature list is a starting point for a demo. Ask the person installing it to show your modifiers, split checks and kitchen workflow in the chosen release. A table record alone does not establish that the whole service will work. The project's installation guide is the place to check the supported setup.

Odoo: check the restaurant module and each add-on

Odoo's public 19.0 restaurant module lists printing a bill before payment, splitting an order and sending order updates to kitchen or bar printers. That module declares LGPL-3 and depends on Point of Sale. This establishes scope for that module; it does not establish the license or price of every app, hosted plan or payment connector sold under the Odoo name.

Ask the installer for the version, edition, module list and terms in writing. Then run the same restaurant checks on that exact setup. A demonstration using paid add-ons does not tell you what a different installation includes.

ERPNext: inspect the retail workflow before treating it as a restaurant system

ERPNext's POS introduction describes retail transactions linked to inventory and accounting. Its workflow guide covers opening a session, adding items, creating a POS invoice and closing the session. Those sources do not establish the table, coursing or kitchen-routing workflow your restaurant may need.

The project repository offers self-hosted and managed-hosting paths, and explicitly marks its quick Docker example as a disposable demo. Keep a trial separate from production. Get the production setup, maintenance owner and any restaurant extensions agreed before moving your live menu or sales records.

Who will own the work after installation?

Fill in this table before comparing software fees. It is a proposed planning worksheet; a blank cell means a job still needs an owner.

Job	Record before launch
Hosting and access	Who controls the account, who can grant access, and how staff get help during service
Menu changes	Who updates items, modifiers, taxes and printer routes, and who checks the result
Updates	Who tests each update on a copy and decides when to put it live
Backups	Who checks that a backup exists and proves it can restore to a separate environment
Hardware	Exact printer, terminal and tablet models, with a named support contact
Exit	Who can export usable menu, sales and accounting records if you change systems

Put paid setup, hosting, support, hardware, payment processing and future custom work on separate lines. Use a quoted cost or leave it unknown. Free access to source code is not a quote for a working restaurant installation.

What should the restaurant test?

Use made-up orders in a test environment with the same hardware and settings planned for service. Record the exact version, result and person responsible for each gap. These are proposed acceptance checks, not results from our own product test.

1. Menu and modifiers: enter a meal with a size, a paid extra, a substitution and a sold-out item. Compare the receipt, kitchen ticket and total.
2. Table service: move an order to another table, split the check and change an item after it reaches the kitchen. Check that staff can tell the change from a new order.
3. Kitchen routing: send food and drinks to their intended stations. Disconnect one printer and check how staff notice and recover the missed ticket.
4. Payments: use the processor's test mode to check approved, declined and interrupted payments, then a refund. Confirm that the sale and payment records agree before staff retry.
5. Connection loss: disconnect the internet and test ordering and payment separately. Record what stops, what remains usable and what happens on reconnection. Our POS offline guide explains that distinction.
6. Closing: close the shift and compare cash, payments, refunds and exported sales with the test orders.
7. Recovery: have the support owner restore a backup into a separate environment and show the recovered menu and records. Keep the live system out of this exercise.

Choose a go-live date only when the restaurant lead and support owner agree on the remaining gaps and fallback. Keep the old records and a staff procedure for a failed terminal or kitchen printer.

Can phone ordering connect to an open-source POS?

Check that as a separate project. An API or public code repository does not prove that a phone agent can create the right order in your installation. Ask both teams to demonstrate the menu mapping, modifiers, accepted order, kitchen ticket, failure notice and safe retry on the exact version you plan to use.

Maple's phone-ordering page describes its supported-POS trial checks. This guide establishes no Maple integration with OSPOS, Odoo or ERPNext. Bring the system name, version and workflow to a Maple demo to check fit before making a purchase.

Published by Maple, which sells restaurant phone AI. This AI-assisted guide uses project documentation and source files reviewed September 30, 2026, plus an original ownership worksheet and test plan. We did not install or benchmark these systems. Project documentation can change; check the exact release and terms with your installer.