Google Cloud Print alternative: what actually replaces it

Google Cloud Print was permanently switched off on 31 December 2020. If you are reading this, you probably still have a workflow that assumed it would always be there: an app that printed a label from a server, a back office that pushed a receipt to a shop counter, a script that sent a work order to a warehouse.

The short answer: nothing from Google replaced it. What replaced it, in practice, is a cloud print API: an HTTPS endpoint you POST to, with a printer that holds an outbound connection to that service. No local print server, no driver on a machine that has to stay awake. Expedy Print is one of those APIs; below is an honest comparison with the other options so you can tell whether it fits your case.

Why Google Cloud Print was retired

Google Cloud Print was a bridge technology. It existed because in 2010, printing from a Chromebook or a phone was genuinely hard. It was never given a stable, documented, versioned API for third-party backends: it was designed around a user clicking "Print" in a browser.

When Google announced the shutdown in 2019, the official guidance was to use native platform printing (CUPS, IPP, mobile print plugins). That advice works for a person printing a document. It does not work at all for the case most people actually had: a server that needs to make paper come out of a machine somewhere else, without a human present.

That gap is what the current generation of tools fills.

What you actually need to replace

Before comparing products, it is worth being precise about the four things Google Cloud Print gave you:

1. Reachability: the printer was addressable from the internet without opening a port on the shop's router.
2. No local software: after the initial registration, no computer had to stay on.
3. A queue: jobs submitted while the printer was offline were not silently lost.
4. Multi-tenancy: one account could hold many printers in many locations.

Any replacement that drops one of these is not a replacement, it is a downgrade. This is the main trap: several "alternatives" quietly reintroduce a computer that must stay powered on next to the printer.

The options in 2026

Option	Local machine required	Direction	Hardware	Best for
Native IPP / CUPS	Yes, a print server	Push, LAN only	None	Office printing on one site
QZ Tray	Yes, a Java applet on the client	Browser to local printer	None	Printing from a web app on the same desk
Star CloudPRNT	No	Printer polls your server	Star range	Shops already standardised on Star
Epson Server Direct Print	No	Printer polls your server	Epson range	Shops already standardised on Epson
PrintNode	Yes, a client app on a computer or Pi	Push via API	None	Existing USB printer fleets with a spare machine
Expedy Print	No	Push via REST API	None (cloud printer or Pi adapter)	Backends that must print unattended

Two structural differences matter more than any feature list.

Push versus poll. CloudPRNT and Server Direct Print invert the relationship: the printer asks your server every few seconds whether there is anything to print. That means you have to build and host that endpoint, keep it available, and accept the polling interval as your latency floor. A push API removes that work entirely: you POST a job and the service delivers it.

Whether a computer must stay on. QZ Tray needs a Java application running on the machine that owns the printer, plus a code-signing certificate if you want silent printing. PrintNode needs its client running on a computer or a Raspberry Pi next to the printer. Both are legitimate designs, but they recreate the failure mode Google Cloud Print users were escaping: someone shuts the laptop, printing stops.

Replacing it with a REST call

With a cloud printer that holds its own outbound connection, printing becomes a single HTTP request from wherever your code already runs:

curl -X POST https://www.expedy.fr/api/v2/printers/{printer_uid}/print \
  -H "Authorization: API_SID:API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "printer_msg": "ORDER #1043\n2x Margherita\n1x Tiramisu\n\nTotal: 28.50 EUR",
    "origin": "my-backend"
  }'

There is no SDK to install and no local daemon. The same call works from Node.js, Python, PHP, Go, Ruby, .NET or a shell script, which matters if the code that used to talk to Google Cloud Print is spread across several services.

For layout (bold lines, logos, QR codes, barcodes, cut commands), see the receipt layout documentation.

Migrating an existing fleet

The migration is usually smaller than people expect, because the Google Cloud Print integration was rarely more than "send this text to this printer id".

1. Inventory what still prints. List every job type and the printer it targets. Most fleets discover that a third of the integrations were abandoned years ago.
2. Decide per site: new printer or adapter. If the existing thermal printer is fine and only needs to become addressable, a Raspberry Pi USB adapter turns it into a REST-addressable cloud printer. If the printer itself is end-of-life, a 4G/Wi-Fi/Ethernet cloud printer removes the local network from the equation entirely: useful in shops where you do not control the router.
3. Map printer ids. Replace the old GCP printer identifier with the new printer_uid in your configuration, not in your code.
4. Run both in parallel for a week. Print to the new endpoint and keep the old path logging only. Any missing job types surface immediately.
5. Handle the offline case explicitly. Decide what should happen when a printer is unreachable: retry, alert, or queue. This is the step teams most often skip, and it is the one that produces "we lost an order" incidents six months later.

Which option fits your case

• You print from a browser, on the same desk as the printer. QZ Tray or plain native printing is simpler than any cloud service.
• All your sites already run Star or Epson hardware, and you enjoy hosting endpoints. CloudPRNT or Server Direct Print will work, at the cost of building the polling server.
• You have a spare always-on computer at each site. PrintNode is a reasonable fit.
• Your backend must print unattended, in places you do not control. A push REST API with a self-connecting printer is the only option that keeps all four Google Cloud Print properties.

Expedy Print sits in that last category. It has a free plan for testing, native connectors for Shopify, WooCommerce and HubRise, and an OpenAPI specification if you want to generate a client. If your use case is one of the first three above, one of the other tools will serve you better, and that is a more useful answer than a sales pitch.

FAQ

When exactly did Google Cloud Print shut down?

It was switched off on 31 December 2020. The shutdown was announced in November 2019, and no Google service replaced it.

Is there a free Google Cloud Print alternative?

Expedy Print has a free plan that covers 50 print requests per month, which is enough to port an integration and test it end to end. Tickets printed on the free plan carry a watermark.

Do I have to buy new printers?

No. A Raspberry Pi USB adapter turns an existing USB thermal, label or desktop printer into a REST-addressable cloud printer. Buying a cloud printer is only necessary when the existing hardware is end-of-life or when there is no usable local network.

What happens to jobs sent while the printer is offline?

They are queued and delivered when the printer reconnects, and the API reports the delivery state so your backend can alert or retry rather than losing the job silently.

Can I keep printing from a browser like Google Cloud Print did?

Yes, but a browser is rarely the right place for it any more. If the print is triggered by a business event (an order, a payment, a shipment) sending it from your backend is more reliable than depending on a tab being open.