Send G-code to multiple printers from one app

One self-hosted app can drive every printer on your network. PrintStash does it with a file library feeding a fleet queue: pick a G-code revision from the vault, then either send it straight to a machine or queue it and let manual, default-printer, or least-busy routing place it. The detail worth knowing up front is that a queued job lands on exactly one printer. There is no button that fans a single file out to the whole fleet, so running the same part on six machines means queueing six jobs and letting the router spread them.

This works today on Moonraker/Klipper, the stable provider. OctoPrint, PrusaLink, Bambu LAN, and Elegoo Centauri are beta, and not all of them can receive files at all; more on that below.

Two jobs hiding in one question

“Send to multiple printers” covers two different jobs, and the queue handles them differently.

The first is batch dispatch: one part needs to run on several machines now. In PrintStash that is several queued jobs from the same revision. Least-busy routing assigns each one to the printer with the least work in front of it, so the copies spread across free machines without you picking each target.

The second is ongoing load balancing: you keep feeding a farm and want each new job to land somewhere sensible. That needs routing logic rather than a copy action, and it is the same queue doing the work. You decide what to print; the router decides which machine runs it, and anything still queued can be reordered or rerouted.

Either way the file stays attached to its history. Every slice in the vault is a revision of its source model with parsed slicer metadata and an outcome, so what you queue is the revision marked known good, not a filename you hope is the right one. Tracking known-good G-code revisions covers that side.

On a Klipper fleet

Connect each printer through its Moonraker endpoint, usually on port 7125. Connecting PrintStash to multiple Klipper printers walks through adding and testing machines one at a time. Moonraker gets the full capability set: live status, upload, start, remote file inventory, pause, resume, cancel, and measured filament consumption for real per-print cost. Queue a job and the dispatcher transfers the file, starts it, tracks the outcome, and records it against the model’s print history.

Access is granted per printer since v0.11.1: a user can hold view, print, control, or admin on each machine independently, and the queue and routing APIs enforce that effective role. An operator can be allowed to start jobs on some machines and only watch others, and printing also requires edit access to the model’s collection.

When a machine needs a nozzle swap, soft-drain mode or a one-off maintenance window takes it out of routing without cancelling what is already running, and the scheduler dispatches around it until the window closes. Queueing and scheduling across a printer farm has the eligibility rules in full, along with the /api/v1/fleet endpoints if you want to drive the queue from a script.

What non-Klipper printers can receive

The beta providers are capability-aware: the app disables actions a printer cannot do instead of failing at send time. OctoPrint and PrusaLink accept uploads and expose a remote file inventory. Bambu Lab printers in LAN mode accept plain-text uploads and opt-in start but expose no file inventory. Elegoo Centauri accepts chunked uploads and print controls, but upload remains beta and file inventory is disabled. The compatibility matrix is the per-provider list and changes with releases.

Limits

Least-busy routing counts work in front of each machine and nothing else, so it does not pick a target by loaded filament or nozzle. Since v0.12.0 a preflight check does compare the file’s material and nozzle metadata against what the printer reports before a direct send, and flags a mismatch you can override with the override recorded, so the machine no longer accepts an ABS slice on a PLA spool without saying anything. Choosing the right target for a queued batch is still the operator’s job. There is also no camera wall and no failure detection, so PrintStash depends on the printer reporting an outcome rather than noticing spaghetti itself. If monitoring is the actual problem, the farm software comparison covers the tools that own it.

Questions that come up

Do all the printers need to be on the same network as PrintStash?

The server has to be able to reach each printer’s address, and PrintStash itself is local-first. For access from outside the LAN, put it behind a VPN or a hardened reverse proxy; running PrintStash behind a reverse proxy with TLS covers that setup.

Will queued jobs survive a server restart?

Yes. Fleet dispatch is database-backed and interrupted background work resumes or is marked retryable after a restart. The one exception is a dispatch interrupted between the provider upload and the final database write, which is recorded with an unknown outcome and not retried automatically, so a restart cannot start the same print twice.

Can I start the same file on six printers with one click?

No. You queue six jobs from the same revision. Least-busy routing spreads them across free machines as work clears, and anything still waiting can be rerouted or reordered from the queue view.

Sources

• PrintStash capabilities and the compatibility matrix.
• PrintStash v0.11.0 release notes for the fleet queue and restart behavior.
• Moonraker/Klipper setup guide.