THE DESIGN DECISION
Control the environment around checkout.
A point-of-sale application inherits the behavior of the machine underneath it. VayaOS takes responsibility for that environment.
The register boots into a dedicated cashier session. The local POS service runs under systemd. The browser is the operator’s display for an application served from the register itself. Staff work inside the retail interface; authorized maintenance uses a separate administrative path.
That changes deployment from installing an application on an arbitrary desktop to preparing a known combination of operating system, application, runtime, and peripherals. HP Engage is the register platform. The cashier’s experience and the service technician’s recovery path are both considered in the build.
A short path from touch to transaction.
Vaya POS interface
Touch controls, barcode input, tender selection, manager tools, and ticket history.
Local Node.js service
Local APIs coordinate catalog queries, checkout, reporting, and hardware adapters.
SQLite on every register
The operational checkout database stays on the lane. PostgreSQL receives store synchronization separately.
Controlled Linux kiosk
A dedicated kiosk account, managed services, local runtime dependencies, and an administrative recovery path.
HP Engage hardware
A defined register family, with scanner, scale, receipt, and payment connections validated per deployment.
Keeping the catalog lookup local avoids making an ordinary scan wait for a remote database round trip. The performance work also limits search results and the quick-menu dataset so the interface does not need to load the entire catalog.
One image. Two register roles.
Checkout stays local.
Its own checkout engine.
Conceptual deployment topology. Each lane requires power and its own functioning local services.
The pilot architecture uses one VayaOS image with a first-boot choice: Store Hub + Register or Additional Register. Register 1 hosts the central PostgreSQL store archive and synchronization services, while its own checkout still uses local SQLite. Additional registers keep their own SQLite database and local device connections.
Pairing identifies the correct Hub on the store network. Station identity and allocated invoice-number ranges distinguish lanes; synchronization brings their records together. Sharing a store does not require every scan to execute against the Hub.
| Responsibility | Every register | Store Hub |
|---|---|---|
| Local product lookup and checkout | Local SQLite and Node.js service | Uses its own local checkout too |
| Device communication | Local scanner, scale, printer, terminal adapters | Its own lane’s devices |
| Store synchronization | Sends and receives updates when connected | Central PostgreSQL endpoint |
| Store-wide history | Depends on available synchronized / archived data | Shared archive for the store |
Vaya Inventory and the Vaya Remote portal are separate projects. The architecture described here is the Core Vaya checkout and VayaOS register environment.
Treat boot as an operating workflow.
The appliance path includes system startup, a dedicated kiosk session, display configuration, local service readiness, and the POS screen. The goal is a predictable return to the register after power-up, without routine desktop navigation.
The Linux work has included Openbox/X11 kiosk behavior, full-screen browser startup, touch mapping, receipt services, and startup timing. A customer display is a distinct output: the cashier’s touchscreen must remain mapped to the cashier display when a second screen is connected.
Build once, inspect the result, validate the device.
The offline installer work packages application dependencies and the authorized PAX runtime with the image. Build manifests and checksums make the contents identifiable. A dependency check proves that packaged software can load; a physical boot, a scale reading, and a payment still require their own acceptance checks.
A controlled update policy provides a repeatable point from which to investigate regressions. Keep the tested image and the device’s configuration associated with the release. The new-image installation path and the update path for existing registers must each be validated.
Make the failure boundaries explicit.
Local checkout removes the central server from ordinary catalog access. It cannot make a register run without power, repair a failed SSD, or authorize a payment when the terminal has no supported route to its processor.
Synchronization and backup also serve different purposes. Synchronization distributes records; a tested backup and restoration process protects recoverability. A local-first deployment needs both operational continuity and a plan for recovering a failed device.
Explore each outage scenario