Writing / October 10, 2026
Printing from the cloud: why a POS needs a bridge, not a local server
A cloud point-of-sale has to talk to receipt and kitchen printers. Here is why a small print bridge beats a locally installed web stack.
Every restaurant POS eventually runs into the same wall: the software lives in the cloud, but the receipt and the kitchen ticket come out of a thermal printer on the counter.
Those printers speak ESC/POS, a compact command language for receipts. A web page cannot talk to one directly, and a cloud server cannot reach a printer sitting behind a restaurant’s router. Something local has to sit in the middle.
The tempting shortcut
The quickest fix is to install a small web server on a computer at the till and have the POS call it. I have seen this work, and I have seen it fail at the worst moment: when the machine updates, when the port is already in use, when a non-technical owner needs to restart it on a Friday night.
A full local web stack is a lot of moving parts to depend on for one job. It is hard to secure, hard to update, and hard to support from a distance.
A smaller shape
Splitting the problem in two makes it far easier to reason about:
- A relay in the cloud. The POS asks the relay to print. The relay knows which printer belongs to which tenant and location, and keeps a record of what was sent.
- A lightweight bridge on site. A small program that holds a connection to the relay and writes ESC/POS to the printer. It has one responsibility and almost nothing to configure.
The bridge never needs to accept inbound connections, so there is nothing to open on the restaurant’s network. Printing becomes a message that travels outward and is acted on locally.
What this buys you
- Less to break. One small, replaceable component instead of an installed web stack.
- Better support. The relay shows what was sent and whether the bridge is connected.
- A cleaner security story. Combined with device enrollment and audit logging, you can say which device printed what, and when.
The lesson I keep relearning
When a cloud product has to touch physical hardware, put the awkward part behind the smallest boundary you can, and make that boundary observable. The rest of the system can stay boring.