What changes when the internet is optional: notes from building OrderRestro

OrderRestro is built so that order-taking, billing, the kitchen display and printing keep working with the restaurant's internet cable unplugged. That sentence sounds like a feature. In practice it is a constraint that touches every module.

One server on the restaurant's network

The default deployment is a single machine on the restaurant's LAN running three containers: PostgreSQL, the API and the web application. Every till, tablet and kitchen screen reaches it by its local address. The identical compose file also runs on a VPS or behind a tunnel, so there is no separate cloud mode to maintain.

What I could not assume

A restaurant system that can assume the internet may fetch fonts, call a payment or print API, look up tax rates and send telemetry. Without that assumption every dependency has to be local or optional. Receipts print through ESC/POS directly. Money arithmetic runs on the server. Anything that does need the outside world, such as sending a message, is an add-on and not a prerequisite.

Live screens need a push channel

The kitchen display, the table map and the order list need the same live state. I used a Socket.IO gateway with a namespace per concern. A ticket that arrives twenty seconds late is a failure staff notice immediately, and on a LAN pushing is cheap.

The cookie that made login look broken

When OrderRestro is reached through an HTTPS tunnel, the session cookie should carry the Secure attribute. I made that a setting. The trap is the reverse. If the flag is on while the user reaches the app over plain HTTP, such as an address on the LAN, the browser silently refuses to store the cookie.

The symptom is confusing. The login request succeeds. The next request carries no cookie and returns Unauthorized. Nothing logs an error because from the server's point of view nothing went wrong. The fix is to set the flag only when traffic arrives over HTTPS, and to say so prominently in the deployment documentation, which I did.

The cost that moves to the owner

Self-hosting removes the subscription and moves backups, updates and hardware failure onto the operator. That is a real burden for a small business, and I do not think it is right for every restaurant. I try to reduce it with a one-command install, a CasaOS app, a thin Windows client for tills and written runbooks, but it does not disappear.