Printing from the cloud to a printer on someone else’s Wi-Fi
Why the agent must dial out, how five printer transports differ, and why the bridge refuses to talk to public addresses.
A cloud server cannot open a connection into a restaurant's network — NAT, firewalls and changing IP addresses see to that. So the connection has to start from inside.
Dial out, then listen
The desktop app opens a WebSocket to the server and keeps it alive (reconnect with backoff from 2 to 60 seconds, treat 90 seconds of silence as a dead link). The server pushes discover and print commands down that pipe.
Five ways to reach a printer
| Transport | Port | Notes |
|---|---|---|
| Raw TCP ("JetDirect") | 9100 | The common case for thermal printers — bytes in, paper out |
| IPP 1.1 | 631 | Try the common endpoint paths |
| LPD (RFC 1179) | 515 | Windows' LPD service acknowledges differently; tolerate it |
| Windows spooler | — | RAW job via FFI, TEXT fallback |
| macOS CUPS | — | lp -o raw so ESC/POS bytes arrive untouched |
Don't become a proxy
Printer addresses come from the server. If the server were compromised, a naive bridge would happily connect to anything it was told to — a classic SSRF shape, now inside a restaurant's LAN. The bridge only connects to private, link-local and loopback addresses.
Queue per printer
One job at a time per printer keeps tickets in order; different printers print in parallel so the bar never waits for the kitchen.
Keep reading
Offline-first is mostly about conflicts
Caching is the easy part. Notes on field-level patches, stale-write refusal and private data when two phones edit the same book offline.
Oct 2026
Reading a million-line file in a browser tab
Workers own the bytes, the main thread owns the pixels, and a scroll position is “line N plus an offset” — not a giant spacer.
Sep 2026