Most sites that want automatic printing already have a printer. It works, staff know it, and the paper is in a cupboard behind it. The problem is never the printing; it is that the printer can only be reached by whatever computer holds the USB cable.
The short answer: a small adapter takes the USB cable on one side and holds an internet connection on the other, which makes the existing printer addressable over REST. No computer stays on, no driver is installed on anyone's machine, and the hardware you already paid for keeps working.
What actually changes
| USB printer alone | With a Pi adapter | |
|---|---|---|
| Reachable from a backend | No | Yes, over REST |
| Needs a computer switched on | Yes | No |
| Driver installed on a workstation | Yes | None |
| Works when nobody is logged in | No | Yes |
| Survives the PC being replaced | No | Yes, it is not involved |
The distinction that matters is the fourth row. A printer attached to a workstation prints when a person is present and logged in. A printer behind an adapter prints because an order arrived.
When the adapter is the right move
- The printer is fine and fairly new. Replacing working hardware to gain connectivity is the expensive way round.
- The model is unusual, a label printer, a card printer, something with a proprietary format your code already produces. Keeping it avoids rewriting the layout.
- A site has several printers, and one adapter with multiple USB ports covers them together.
- You are retrofitting an estate where replacing every unit at once is not realistic, and you would rather convert progressively.
When to buy a cloud printer instead
Be honest about the cases where the adapter is not the better answer:
- The printer is failing. An adapter on a dying print head buys nothing.
- The site has no usable network. An adapter still needs to reach the internet. If the venue has no reliable connection and no cable is possible, a printer with its own SIM solves a problem the adapter cannot.
- You want one supported model across many sites. Uniform hardware is worth real money in support terms, and mixed fleets cost more to document.
The printer selection guide goes through that trade in detail.
Setting it up
The physical part is short: power, network, and the USB cable from the printer. The Raspberry Pi installation guide covers the install, and the USB print endpoint documents addressing a specific port when several printers share one adapter.
Two things are worth doing before it goes on a wall:
Print a test ticket from a plain curl before wiring your application to it. If the ticket comes out, the chain is proven and any later problem is in your code rather than in the hardware.
Note which USB port each printer uses. With a multi-port adapter the port is part of the address, and finding out at 20:00 which of three printers is port two is not the moment to learn.
What the adapter does not solve
It does not make a bad location good. Above a fryer, or on the far side of a room from the access point, the same physical problems apply as to any printer.
It does not remove the venue network from the chain. The adapter connects outward, which is why no port forwarding or VPN is needed, but it still needs a connection. In premises where you do not control the router, that dependency remains, and a 4G printer is the only thing that removes it.
It does not change the ticket. Layout, character encoding and cutting behaviour are properties of the printer and of what you send it, so an emoji in a product name will misbehave exactly as before. Transliterate before sending, as covered in the receipt layout reference.
A sensible order of operations
- Confirm the printer prints something from its own test function.
- Attach the adapter, then print a test ticket with curl.
- Wire your backend and print a real order in a quiet period.
- Only then mount everything in its final position.
Doing step four first is the common mistake, and it turns a ten-minute diagnosis into an afternoon with a screwdriver.
Create a free account and print the test ticket before the adapter leaves the desk. The same REST call then works unchanged whether the printer is a cloud model or an old USB unit behind an adapter, which is the entire point of doing it this way.
FAQ
Can I keep my existing USB printer and still print from the cloud?
Yes. A Raspberry Pi USB adapter holds the internet connection and exposes the printer over REST. No computer has to stay switched on and no driver is installed on anyone's workstation.
Does the adapter need port forwarding or a VPN?
No. It establishes its own outbound connection, which is what avoids touching the router. It does still need some internet access, so a site with no usable network needs a printer with its own SIM instead.
Can one adapter drive several printers?
Yes, through its USB ports, and the port is part of the print address. Note down which printer is on which port during installation rather than discovering it during service.
When is it better to buy a cloud printer than to add an adapter?
When the printer is already failing, when the site has no reliable network and needs 4G, or when standardising many sites on one supported model is worth more than saving on individual units.
Does an adapter fix garbled tickets or emoji problems?
No. Character encoding and layout depend on the printer and on what you send it, so transliterate item names before building the ticket exactly as you would with any thermal printer.