laravel-printing: sending receipts and PDFs straight to a LAN printer

The problem it solves: the printer is on the other side of the internet

Printing for Laravel allows your application to directly send PDF documents or raw text from a remote server to a printer on your local network. That sentence contains the whole use case, and the topology is what makes it interesting.

The printer is on a local network. Your application server is not. A browser cannot print to a network printer directly, because the print spool lives behind a firewall and a print server that the browser has no way to reach. The usual workarounds are all unsatisfying: shipping a file to the user and asking them to print it, running a print agent on the user's machine, or exposing a print server to the internet.

This package takes the third approach but makes it manageable. The server talks to a print server that the local network can reach, and the print server holds the connection to the printer.

The API is small. You build a print task, name the printer, point it at a file, and send it:

$printJob = Printing::newPrintTask()
    ->printer($printerId)
    ->file('path_to_file.pdf')
    ->send();

$printJob->id(); // the id number returned from the print server

The return value is a job identifier from the print server, which is the one thing worth noting. A print job is asynchronous, so the id is what you use to find out what happened later rather than assuming the document printed.

The package is published on Packagist as rawilk/laravel-printing, MIT licensed, the last push was on 2026-09-14, and the recent releases are v4.3.0 on 2026-07-21, v4.2.0 on 2026-06-29 and v4.1.0 on 2025-06-09.

Three drivers, and the receipt case that is not a PDF

Three print drivers are supported.

PrintNode is a hosted print service, and its documentation is linked from the README. CUPS is the standard Linux printing system, and the documentation is linked too. The third option is Custom, described as configuring your own custom driver.

That third option is the one that determines the shape of the deployment. PrintNode means you send the job to a hosted service that then talks to the printer. CUPS means you talk to a local print server yourself, which is the classic setup and means the package can post straight to a spooler on the same LAN as the printer. A custom driver means you implement the interface yourself, which is the route for a printer protocol that neither of the two covers.

The second capability is receipts, and it is separate from the PDF path. The README describes generating the raw text first via the Rawilk\Printing\Receipts\ReceiptPrinter class, and then sending that text as a raw print job via the Printing facade.

That split is the design point. A receipt is not a document, it is a stream of characters in a printer's own language, often ESC/POS, and a PDF would be the wrong container for it. The package handles the text case as a first class path rather than something you build yourself on top of the PDF path.

The credits list names the library this leans on: Mike42 for the PHP ESC/POS Print Driver, escpos-php. That is a standalone package for talking to thermal receipt printers, and it is worth knowing that it exists and is maintained separately, because the receipt path in this package is a thin layer over it rather than a from-scratch ESC/POS implementation.

The topic list of the repository confirms the scope, with cups, ipp, printer, printnode and laravel-printing among the tags.

Installing it, publishing the config, and the fact that it installs nothing else

The installation is a Composer require:

composer require rawilk/laravel-printing

and the configuration file is published with an artisan command:

php artisan vendor:publish --tag="printing-config"

The default configuration lives at config/printing.php in the repository, which is where you look after publishing to see what the driver settings look like before you change them.

The important thing about that sequence is what the package does not do. There is no separate print server to install and no agent to deploy as part of the Composer step. The CUPS driver talks to an existing print server, the PrintNode driver talks to a hosted service, and a custom driver is something you write. Which means the real work of the integration is on the network side of the deployment, not in the Laravel application.

That is worth being explicit about, because the documentation link is the piece that will answer the questions the README does not. The documentation lives at randallwilk.dev/docs/laravel-printing, and the README sends you there rather than reproducing it.

The repository layout is conventional for a Laravel package. There is a src/ directory with the implementation, a config/ directory, a tests/ directory, a docs/ directory, a composer.json, a phpunit.xml.dist for the test configuration, a pint.json for code style, an .editorconfig, a .github directory with the workflows and the contributing guide, plus CHANGELOG.md and LICENSE.md.

Running the tests is a Composer script:

composer test

And the changelog is the file to watch, since the project has been releasing regularly and the driver behaviour is the part most likely to change between minor versions.

The print job lifecycle and what the returned id is for

The example in the README is four lines, and each of them maps onto a stage of the job, which is worth unpacking because the API is fluent and the semantics are not obvious from the shape.

Printing::newPrintTask() starts a task, which is a builder rather than a call that prints anything. The printer method takes the identifier of the target printer, which is a value your configuration or your data provides rather than something the package discovers. The file method points at a document on disk, and the send method performs the delivery to whichever driver is configured.

Only after send does anything reach the printer, and the task then exposes the id number returned from the print server through the id method.

That id is the interesting part of the API, and it is the only output the example returns. A print job is a request to a print server, and the server accepts it before anything has reached the printer. So the id is what you would store against an order, a ticket or a shift, and it is what you would query later to find out whether the job succeeded.

There is no callback in the example and no polling helper, which tells you the package leaves job status to you. If your application needs to know that a receipt printed rather than that a print job was accepted, that reporting has to be built on top of the driver's own interface, and the driver you choose determines what is available.

The fluent style also means the same builder shape works for both document and receipt paths. A receipt is generated as text and then sent as a raw print job through the same facade, so the code that dispatches a job does not need to know whether the payload was a PDF or a stream of receipt characters.

The one thing to check in the documentation rather than here is which methods the builder exposes beyond these four, since the README only demonstrates the path method and the id accessor, and the full list is what the docs site is for.

Where the design came from, and the boundaries the project states

The credits section is unusually specific about lineage, and reading it tells you what is original and what is adapted.

The PrintNode API wrapper is inspired by two existing implementations, the PrintNode PHP client and a fork of it by PhatKoala. Certain aspects of the API implementations are inspired by stripe-php. The author is Randall Wilk, and the contributors list is the usual one.

The ESC/POS credit to Mike42 is the other one that matters technically, since the receipt path depends on that library rather than reimplementing the protocol.

The disclaimer states that this package is not affiliated with, maintained, authorized, endorsed or sponsored by Laravel or any of its affiliates. That is a fairly common line in a package published under the Laravel name, and it is worth noting because the package name and namespace make it look like first-party work. The homepage is randallwilk.dev/docs/laravel-printing, a personal docs site, and the security contact is a direct email address rather than the issue tracker, with the README asking that security related issues be emailed to [email protected] instead of filed as an issue.

The licence is MIT, with the text in LICENSE.md.

What the package does not attempt is also clear from the shape of it. There is no PDF generation, no receipt templating engine, no printer discovery, and no print job queue. It is a delivery layer: you have a file or a string of receipt text, and this gets it to a printer somewhere on a local network. Everything around that, the document format, the template, the queueing, the retry policy, is yours.

That narrowness is the appeal. A package that did all of those things would be a framework, and the hard parts of printing are rarely the transport.

Editorial conclusion

Adopt laravel-printing when your Laravel application has to produce a physical receipt or document on a printer that lives on someone's local network rather than in your datacenter, and you need text output as well as PDF. Do not adopt it for PDF generation itself, since it does not create documents, it only delivers them. Before you wire it up, decide which driver you are targeting, since PrintNode, CUPS and custom drivers have different deployment shapes, and note that the package is not affiliated with or endorsed by Laravel.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. rawilk/laravel-printing on GitHub
4. README
5. Releases