Google Cloud Print wurde am 31. Dezember 2020 endgültig abgeschaltet. Wenn Sie das hier lesen, haben Sie vermutlich noch einen Workflow, der davon ausging, dass es immer da sein würde: eine Anwendung, die vom Server ein Etikett druckte, ein Backoffice, das einen Beleg an den Tresen eines Ladens schickte, ein Skript, das einen Arbeitsauftrag ins Lager sendete.
Kurze Antwort: Von Google kam kein Ersatz. Ersetzt wurde es in der Praxis durch eine Cloud-Print-API: einen HTTPS-Endpunkt, an den Sie eine Anfrage senden, mit einem Drucker, der selbst eine ausgehende Verbindung zu diesem Dienst hält. Kein lokaler Druckserver, kein Treiber auf einem Rechner, der eingeschaltet bleiben muss.
Warum es eingestellt wurde
Google Cloud Print war eine Übergangstechnologie. Es existierte, weil Drucken von einem Chromebook oder Handy im Jahr 2010 wirklich schwierig war. Es bekam nie eine stabile, dokumentierte, versionierte API für Backends von Drittanbietern: es war um einen Nutzer herum gebaut, der im Browser auf „Drucken" klickt.
Bei der Ankündigung 2019 lautete die offizielle Empfehlung, native Plattformdruckdienste zu nutzen (CUPS, IPP, mobile Druck-Plugins). Dieser Rat funktioniert für eine Person, die ein Dokument druckt. Er löst überhaupt nicht den Fall, den die meisten tatsächlich hatten: ein Server, der dafür sorgen muss, dass anderswo Papier aus einer Maschine kommt, ohne dass jemand anwesend ist.
Was tatsächlich ersetzt werden muss
Vier Dinge lieferte Google Cloud Print:
- Erreichbarkeit: der Drucker war aus dem Internet ansprechbar, ohne einen Port am Router des Ladens zu öffnen.
- Keine lokale Software: nach der Registrierung musste kein Rechner eingeschaltet bleiben.
- Eine Warteschlange: Aufträge, die bei offlinem Drucker abgeschickt wurden, gingen nicht stillschweigend verloren.
- Mandantenfähigkeit: ein Konto konnte viele Drucker an vielen Standorten führen.
Ein Ersatz, der eines davon fallen lässt, ist kein Ersatz, sondern ein Rückschritt. Das ist die Hauptfalle: Mehrere „Alternativen" führen still einen Rechner wieder ein, der neben dem Drucker eingeschaltet bleiben muss.
Die Optionen 2026
| Option | Lokale Maschine nötig | Richtung | Hardware | Geeignet für |
|---|---|---|---|---|
| Natives IPP / CUPS | Ja, ein Druckserver | Push, nur LAN | Keine | Bürodruck an einem Standort |
| QZ Tray | Ja, ein Java-Applet | Browser zum lokalen Drucker | Keine | Drucken aus einer Web-App am selben Platz |
| Star CloudPRNT | Nein | Drucker fragt Ihren Server | Nur Star | Bereits auf Star standardisierte Flotten |
| Epson Server Direct Print | Nein | Drucker fragt Ihren Server | Nur Epson | Bereits auf Epson standardisierte Flotten |
| PrintNode | Ja, ein Client pro Standort | Push per API | Keine | Bestehende USB-Flotten mit freiem Rechner |
| Expedy Print | Nein | Push per REST-API | Keine | Backends, die unbeaufsichtigt drucken |
Zwei strukturelle Unterschiede wiegen schwerer als jede Funktionsliste.
Push gegen Polling. CloudPRNT und Server Direct Print drehen die Beziehung um: Der Drucker fragt alle paar Sekunden Ihren Server, ob es etwas zu drucken gibt. Sie müssen diesen Endpunkt bauen und betreiben, seine Verfügbarkeit garantieren und das Polling-Intervall als Latenzuntergrenze hinnehmen.
Ob ein Rechner laufen muss. QZ Tray braucht eine Java-Anwendung auf dem Rechner mit dem Drucker, plus ein Code-Signing-Zertifikat für stilles Drucken. PrintNode braucht seinen Client auf einem Rechner neben dem Drucker. Beide erzeugen genau den Fehlerfall neu, dem Google-Cloud-Print-Nutzer entkommen wollten: Jemand klappt den Laptop zu, und es wird nicht mehr gedruckt.
Ersatz durch einen REST-Aufruf
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": "BESTELLUNG #1043\n2x Margherita\n1x Tiramisu\n\nSumme: 28,50 EUR",
"origin": "mein-backend"
}'
Kein SDK, kein lokaler Dienst. Derselbe Aufruf funktioniert aus Node.js, Python, PHP, Go, Ruby, .NET oder einem Shell-Skript. Für das Layout (Fettdruck, Logos, QR-Codes, Barcodes, Schnitt), siehe die Layout-Dokumentation.
Eine bestehende Flotte migrieren
- Inventarisieren, was noch druckt. Die meisten Flotten stellen fest, dass ein Drittel der Integrationen seit Jahren tot ist.
- Pro Standort entscheiden: neuer Drucker oder Adapter. Funktioniert der vorhandene Thermodrucker, macht ein Raspberry-Pi-USB-Adapter ihn per REST ansprechbar. Ist er am Lebensende, nimmt ein 4G/WLAN/Ethernet-Cloud-Drucker das lokale Netz ganz aus der Gleichung.
- Kennungen zuordnen. Die alte GCP-Drucker-ID wird zur neuen
printer_uid: in der Konfiguration, nicht im Code. - Eine Woche parallel fahren. Vergessene Dokumenttypen zeigen sich sofort.
- Den Offline-Fall ausdrücklich behandeln. Dieser Schritt wird am häufigsten übersprungen und erzeugt ein halbes Jahr später die „Wir haben eine Bestellung verloren"-Vorfälle.
Welche Option zu welchem Fall passt
- Sie drucken aus dem Browser, am selben Tisch wie der Drucker. QZ Tray oder nativer Druck ist einfacher.
- Ihre Standorte laufen bereits vollständig auf Star- oder Epson-Hardware. CloudPRNT oder Server Direct Print funktioniert: zum Preis des Polling-Servers.
- An jedem Standort steht ein dauerhaft eingeschalteter Rechner. PrintNode ist eine vernünftige Wahl.
- Ihr Backend muss unbeaufsichtigt drucken, an Orten, die Sie nicht kontrollieren. Eine Push-REST-API mit selbstverbindendem Drucker ist die einzige Option, die alle vier Eigenschaften von Google Cloud Print erhält.
Expedy Print gehört in diese letzte Kategorie, mit kostenlosem Tarif und Konnektoren für Shopify, WooCommerce und HubRise.
FAQ
Wann genau wurde Google Cloud Print abgeschaltet?
Am 31. Dezember 2020. Die Abschaltung wurde im November 2019 angekündigt, und kein Google-Dienst hat es ersetzt.
Gibt es eine kostenlose Google-Cloud-Print-Alternative?
Expedy Print bietet einen kostenlosen Tarif mit 50 Druckanfragen pro Monat: genug, um eine Integration zu portieren und durchgängig zu testen. Belege im Gratistarif tragen ein Wasserzeichen.
Muss ich neue Drucker kaufen?
Nein. Ein Raspberry-Pi-USB-Adapter macht einen vorhandenen USB-Drucker per REST ansprechbar. Ein Cloud-Drucker ist nur nötig, wenn die Hardware am Lebensende ist oder kein brauchbares lokales Netz existiert.
Was passiert mit Aufträgen, während der Drucker offline ist?
Sie werden in die Warteschlange gestellt und bei der Wiederverbindung zugestellt. Die API meldet den Zustellstatus, sodass Ihr Backend alarmieren oder wiederholen kann, statt den Auftrag stillschweigend zu verlieren.