The 1.9.0 release of OrderRestro adds two-way server sync for embedded installs. I wanted the feature to solve a practical deployment problem without changing the product’s basic promise: a restaurant should be able to run its core workflow on its own local server.
Why build sync for an embedded install?
OrderRestro is an open-source, self-hosted restaurant POS and management system. In a local setup, the web app, API, and PostgreSQL database run on a server inside the restaurant’s network. That keeps order taking, billing, kitchen tickets, and printing available even when the internet connection is down.
Some operators still need a way to exchange data with a separate server. Until now, the local-first model and a central view could feel like competing choices. The new sync path gives installations a way to push and pull changes when configured, while leaving the local stack as the branch’s working system.
What changed in 1.9.0
The implementation uses change-log-triggered synchronization and key-authenticated push/pull requests. There are controls in Settings and in the launcher, so an operator can see that sync is a configured capability rather than an invisible dependency.
That shape matters to me. When software moves operational data between systems, the connection should have an explicit boundary and a clear owner. A restaurant should know which installation it is pairing with and have a place to manage that setup.
The release is built on the sync implementation added immediately before it. The release history is available at the OrderRestro repository, and the project’s README describes the local-server model and installation options.
What this feature does not claim
This is a new capability, not a claim that every multi-branch topology is automatically conflict-free. It is not a replacement for backups, and it does not remove the need to test recovery. Before using sync with live operational data, I recommend setting up a copy, checking the intended direction of exchange, and rehearsing what happens after a network interruption.
I’m especially interested in feedback from people running self-hosted software across locations: which information do you need to trust sync during a shift? A last-successful-sync timestamp, a count of pending changes, a visible retry queue, or a review screen for conflicts?
OrderRestro is developed by NodeDR Infotech Private Limited and is licensed under AGPL-3.0. The source and roadmap are public. If you try the 1.9.0 sync workflow, I’d appreciate concrete notes about where the setup is unclear or what you need to inspect before trusting it.
I share more about my work on RaktimRanjit.com.
Top comments (0)