NexoPOS keeps the core free of restaurants, multi-store and payroll

The scope boundary is stated before the feature list

NexoPOS is described as a modern, extensible point-of-sale platform for retail stores, restaurants, cafés, warehouses and other product or service based businesses, bringing sales, inventory, customers, purchasing, accounting, reporting and staff operations together in one application.

The design principle follows immediately: it is designed to start as a single-store POS and grow with the business, while multi-store, restaurant, service, workforce, rental, AI, printing and other workflows are delivered through modules.

That sentence is the most important one in the README, because it defines what you get from the repository and what you do not. Restaurants are named as a supported business type, and the restaurant features are a module.

The core provides eight groups of things.

Product, category, unit, tax and customer management. POS sales, orders, payments, receipts, refunds and registers. Inventory, procurement, stock history and low-stock workflows. Accounting and operational reporting with configurable stock and cost visibility.

Then customer groups, rewards, coupons and store configuration. User roles, permissions, activity tracking and audit-friendly workflows. Barcode and scale barcode support. And media management, dashboard widgets and extensibility APIs.

The last bullet is the mechanism: a module system for adding business-specific features without changing the core.

That boundary is a deliberate product decision rather than an accident of development. A restaurant POS and a retail POS have different data models, and putting both in one core would make both worse.

The marketplace is where the interesting features live

The module table is the most useful part of the README for an evaluator, because it is a map of what the core deliberately leaves out.

The framing sentence matters. Those modules are distributed separately from the core through the marketplace, they are not included in this repository, and you install them when they match your NexoPOS version.

Fourteen are listed with what each adds.

`BellSera` covers service appointments, public booking, staff and room availability, walk-in and booking order types, service queues and reporting, which is the whole salon and spa workflow. `Gastro` adds restaurant tables, waiter and chef workflows, kitchen screens, order routing and product modifiers. `QR Menu` generates branded digital menus from the catalogue.

`MultiStore` manages multiple isolated stores from one installation and database. `Rental` adds reservations, agreements, inventory movements, returns and maintenance. `WorkForce` covers kiosk attendance, breaks, schedules, timesheets, corrections and private reports, which is the payroll precursor.

Then the operational ones. `PIN Login` for fast POS login and inactivity locking. `Google Authenticator` for time-based two-factor authentication. `NPS Adapter` for local and network printing. `Sales Commissions` for commission rules and tracking. `Bulk Editor` for bulk editing supported resources. `Options Export/Import` for moving module settings between installations. And `Quick Store Configuration` as guided setup.

`Oxen` is the one with a different shape. It is described as a permission-aware AI agent offering assistance, approved store-management actions, reports and MCP access.

A permission-aware agent with approval-controlled mutations and MCP access is a different category of risk from a kitchen screen module, and it is worth reading its marketplace listing rather than the summary line.

A Vue 3 and Tailwind 4 frontend on Node 24

The frontend stack is modern for a Laravel application, and the package manifest shows it plainly.

Vue is at 3.5 with Vue Router, so this is a single-page application talking to a Laravel API, not Blade templates with islands of Vue.

Tailwind is at version 4, used through both `@tailwindcss/postcss` and `@tailwindcss/vite`, with a `tailwind.config.js` still present. Vite is at 7 with the Vue plugin and `laravel-vite-plugin`, and the scripts are the standard trio: `build` runs `vite build`, `dev` runs `vite`, and `watch` builds in watch mode.

The dependency list is where you can tell what the application actually does.

`ckeditor5` with its Vue wrapper is a rich text editor. `chart.js` with `vue-chartjs` is reporting. `qrcode` and `qrcode-vue` are for the QR menu and receipts. `mathjs` is for calculations, `currency.js` and `numeral` for money formatting and `moment` for dates.

`socket.io-client` and `laravel-echo` are realtime, and `pusher-js` is present alongside them, so the same feature can run over either transport. `vuedraggable` and `sortablejs` are drag and drop, which is how a POS builds an order by touch.

`dompurify` sanitises HTML, which matters because you render markup from a rich text editor. `marked` parses Markdown. `driver.js` runs the product tour. `rxjs` is the reactive streams library, and `@wordpress/hooks` is a JavaScript hook system, which is how front-end extensions can register behaviour.

The engine requirement is pinned to Node 24.x, so this is not a stack you can build with whatever Node is installed.

The environment file is a deployment checklist

The `.env.example` is long, and reading it is the fastest way to understand what running this application involves.

The database is MySQL, not PostgreSQL, with the usual host, port, database, username and password.

The defaults are the cautious ones for a development machine: `BROADCAST_DRIVER=log`, `CACHE_DRIVER=file`, `QUEUE_CONNECTION=sync`, `SESSION_DRIVER=file` with a lifetime of 120. Synchronous queues means jobs run inside the request, which is right for development and wrong for production.

Storage is split between local disk and S3, with AWS keys and a bucket. If you have never set AWS credentials the local driver is used.

Realtime has three separate blocks, which is more configuration than most applications need. Pusher has an app id, key, secret and cluster, plus two `MIX_` prefixed variables for the client. Laravel Echo and Reverb then have their own block with a server host, host, port and scheme, and the file carries comments questioning whether the scheme setting is effective. `TELESCOPE_ENABLED=false` closes off Laravel Telescope by default.

Two entries are worth noticing because they are easy to miss. `SANCTUM_STATEFUL_DOMAINS` lists the origins Sanctum will accept, and it already names `http://127.0.0.1:8000/`, `http://localhost/` and `http://127.0.0.1/`, which is the SPA talking to the API during development. Get that wrong and you get authentication failures with no useful message.

And the last one is `TRANSLATOR_ENDPOINT`, described as the base URL of an external translation service. That is a runtime dependency on a separate service for translating the interface, with `host.docker.internal:3000` given as the example, which suggests it runs in another container.

Playwright for the browser tests, jest for the rest

Testing is where a POS application differs from a typical Laravel package, because the thing that matters is a cashier tapping a touchscreen.

The scripts tell the story. `test` runs jest, which is the JavaScript unit testing. `test:e2e` runs `playwright test`.

Then the five variants around it. `test:e2e:ui` runs Playwright in UI mode bound to `0.0.0.0` on port 3333, which means the Playwright inspector is reachable from another machine rather than only localhost. `test:e2e:headed` runs the browser visibly instead of headless. `test:e2e:debug` runs under the Playwright debugger. `test:e2e:report` serves the generated report bound to `0.0.0.0`.

And `test:e2e:codegen` points at a script in the repository, `playwright/codegen.sh`, which is Playwright's code generator. For a POS that means recording a cashier interaction and turning it into a test.

The repository also has `phpunit.xml`, so there is a PHP test suite as well as the JavaScript one, plus a `tests/` directory and a separate `ts-tests/` directory for TypeScript tests.

Binding the UI mode and the report to `0.0.0.0` is worth noting on its own. It is the right choice for a container or a remote development box and the wrong choice on a shared network, since the Playwright inspector can execute code in the test browser.

The release history shows steady work: 6.2.2 on 2026-08-25, 6.2.3 on 2026-09-10 and 6.2.4 on 2026-10-02, with the last push on 2026-10-14. The licence is GPL-3.0, which matters if you intend to modify and deploy it rather than run it as is.

Editorial conclusion

Adopt NexoPOS if you run a retail till and want inventory, purchasing and accounting in one application on Laravel. Skip it if your business model needs restaurant service or appointments on day one, since those are paid modules and the free core will not get you there. Verify first which core version a module supports, since the README instructs you to install from the marketplace and confirm the module matches your core version.

Frequently asked questions

Official sources

1. Blair2004/NexoPOS on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases