Most comparison pages on this subject are feature checklists where one column happens to be all green. This one is organised around the three questions that actually determine which tool you can use: the answers rule options out long before any feature does.
The short answer: ask (1) does something have to run on site, (2) who initiates the connection, and (3) are you tied to one printer brand. Once those three are answered for your situation, usually only one or two options remain.
The three deciding questions
1. Can something run on site permanently? A computer, a POS terminal, a Raspberry Pi with your software on it. If yes, PrintNode and QZ Tray are open to you. If no (because the premises belong to your customers, because there are two hundred of them, or because nobody there can restart anything), you need a printer that connects on its own.
2. Who initiates: your server, or the printer? Push means your backend calls an API and the service delivers. Poll means the printer repeatedly asks a server you host. Polling architectures (CloudPRNT, Epson Server Direct Print) hand you the availability, the queue and the exactly-once semantics.
3. How many integrations will you maintain? Each manufacturer implements its own protocol for its own range: CloudPRNT for Star, Server Direct Print for Epson. That is reasonable on their side: they sell printers, not integration layers. But it means one integration per brand, and fleets stop being homogeneous the moment a second site opens. A print platform's job is the layer above: one endpoint whatever the hardware, plus the connectors between an order and a ticket that no printer maker ships.
Side by side
| Runs on site | Initiator | Hardware | Latency floor | You host | |
|---|---|---|---|---|---|
| Native IPP / CUPS | Print server | Push, LAN only | Any | Network | The print server |
| QZ Tray | Java app per workstation | Browser | Any local | Instant | Nothing (but a certificate) |
| PrintNode | Client app per site | Push | Any | Sub-second | Nothing |
| Star CloudPRNT | Nothing | Printer polls you | Star only | Poll interval | The endpoint |
| Epson Server Direct Print | Nothing | Printer polls you | Epson only | Poll interval | The endpoint |
| Expedy Print | Nothing | Push | Any (cloud printer or Pi adapter) | Sub-second | Nothing |
Reading the table honestly
Nothing here is bad. Each option is the best choice for some situation. IPP is the correct answer for an office printing documents on one LAN, and dragging that through a cloud API would be absurd. QZ Tray is the correct answer for a counter operator sending raw ESC/POS from a web app to the printer next to them.
The "runs on site" column is where most projects are decided. It is the column that determines whether your support burden grows linearly with the number of customers. A client application is fine when you administer the machine; it becomes the dominant cost when you do not.
The "you host" column is where most projects are surprised. Building a CloudPRNT endpoint takes an afternoon. Operating it (availability, queue, retries, exactly-once delivery, on-call) is ongoing, and it is rarely budgeted at the start.
Latency only matters sometimes. For a warehouse picking list, a three-second polling delay is irrelevant. For a kitchen during service, it is the difference between a ticket that arrives with the order and one that arrives after the customer has left.
Choosing in one paragraph
If everything is on one LAN and a person clicks Print: use native printing. If a web app must reach the printer on the same desk with raw commands: QZ Tray. If every site has a maintained always-on computer and you would rather not touch hardware: PrintNode. If your estate is entirely Star or entirely Epson and hosting an endpoint is acceptable: CloudPRNT or Server Direct Print. If your backend must print unattended, in locations you do not control, across whatever hardware each site happens to own: a vendor-neutral push API.
Expedy Print is built for that last case: a REST API, cloud printers that connect over 4G, Wi-Fi or Ethernet, a Raspberry Pi adapter for existing USB printers, and connectors for Shopify, WooCommerce, HubRise and Zapier. If your answers to the three questions point somewhere else, one of the other tools will serve you better.
Going deeper
- Google Cloud Print alternative: migrating off the service that shut down in 2020
- PrintNode alternative: when the client app is the constraint
- Star CloudPRNT alternative: the real cost of hosting the polling endpoint
- QZ Tray alternative: moving the call from the browser to the server
FAQ
What is the most important criterion when choosing a cloud print API?
Whether something must run on site. That single question decides whether your support burden grows with each customer, and it rules options in or out before any feature comparison matters.
What is the difference between push and poll printing?
With push, your backend calls an API and the service delivers the job. With poll, the printer repeatedly asks a server you host whether there is work, which makes you responsible for that server's availability and queue.
Which options lock me to one printer brand?
Star CloudPRNT requires Star printers and Epson Server Direct Print requires Epson printers. IPP, QZ Tray, PrintNode and Expedy Print are vendor-neutral.
Does latency actually matter?
It depends on the use case. A few seconds is irrelevant for a warehouse picking list and decisive for a kitchen ticket during service, where it is the difference between the ticket arriving with the order or after the customer has left.
Can I use more than one of these at once?
Yes, and many teams do. Operator-driven prints at a counter can stay on QZ Tray or native printing while event-driven prints move to a push API.