Star 168 Get Started
← Blog

Self-hosted print farm management for Klipper

How a Klipper farm splits into per-printer control, job dispatch, and a file library, with the current self-hosted options for each layer and their licensing.

print-farmklipperself-hostedcomparison

A Klipper farm is three separate jobs, and the tool that does one of them well usually does not do the other two. Moonraker with Mainsail or Fluidd controls a single machine and stays in place whatever else you add. Dispatch across machines needs something that holds a queue and decides which printer gets the next job. The sliced files have to live somewhere, along with the record of which revision actually printed well. PrintStash covers the library and, since v0.11.0, a fleet queue that dispatches over Moonraker. FDM Monster, O.D.I.N., AutoFarm3D, and print-farm-manager cover dispatch with different licensing and different amounts of file handling.

Tool details below were checked against each project’s public pages and repositories on August 3, 2026. There are no sponsored placements or affiliate links.

The per-printer interface stays

Nothing in this article replaces Mainsail or Fluidd. When a first layer goes wrong at 2am, you want the interface that can jog the head, run PID_CALIBRATE, tail klippy.log, and edit printer.cfg. Farm software talks to Moonraker over its API and does not reimplement any of that.

In practice Moonraker is where the layers meet. Anything that speaks its API can sit next to your existing dashboards without touching the printer configuration, which is why a farm layer and a per-printer layer coexist instead of competing. PrintStash works this way too, as described in running alongside OctoPrint, Fluidd, and Mainsail.

The dispatch layer

This is where the tools genuinely differ, mostly on licensing and on how much they know about your files.

Tool Licensing Klipper support Holds a model library
FDM Monster AGPL-3.0, free Moonraker, plus OctoPrint, PrusaLink, Bambu LAN G-code files and thumbnails, not source meshes
print-farm-manager MIT, free Moonraker, plus OctoPrint, PrusaLink, Bambu, Elegoo No, G-code dispatch only
O.D.I.N. BSL 1.1, free for 5 printers and 1 user, paid commercially Moonraker, plus Bambu MQTT, PrusaLink, Elegoo SDCP Not documented as a library feature
AutoFarm3D Commercial, from $29.99/month plus per-printer fees Not stated on the product page Slicer-oriented, not a model library
PrintStash AGPL-3.0, free Moonraker stable, four other providers in beta Yes, source meshes plus G-code revisions

Some notes that the table flattens.

FDM Monster is the closest thing to a general-purpose free farm server. It runs from Docker on amd64 and arm64, ships a Raspberry Pi image and an Unraid app, and covers printer grids, batch printing, queueing, and G-code handling with thumbnails.

print-farm-manager is deliberately narrow: live fleet view, automated dispatch to idle printers, and an operator confirmation step before each subsequent job starts. You upload G-code and define projects and parts. It is not trying to be your library. Its own documentation warns against exposing it to the internet because printer API keys are served to any client that can reach the server, which is worth taking seriously.

O.D.I.N. is the most production-shaped of the group, pitching itself as MES meets SCADA with job scheduling that includes color-match scoring and time-window matching, plus ONNX-based failure detection. Its Business Source License 1.1 converts to Apache 2.0 on February 7, 2029. The free community tier stops at five printers and one user, so a shared workshop hits that limit quickly.

AutoFarm3D is local rather than cloud-hosted despite the subscription, with a free download for Raspberry Pi 4 and paid tiers starting at $29.99 per month annually plus per-printer charges. Its product page lists slicer compatibility with Cura, PrusaSlicer, Orca, and Bambu Studio but does not state Moonraker support, so verify that against your machines before committing.

One name you will still see recommended is OctoFarm. Its last tagged release is v1.7.3 from October 2022, and it only ever managed OctoPrint instances, so a Klipper farm gets nothing from it today.

The library layer

Dispatch answers “which printer runs this next”. It does not answer “which of the six slices of this bracket was the one that came out right”, and that question gets expensive as a farm accumulates history.

PrintStash indexes STL, 3MF, OBJ, STEP, G-code, and BGCODE into one searchable library, either uploaded or indexed in place from a NAS folder. G-code stays attached to its source model as a revision with parsed slicer metadata, and each revision carries an outcome: needs_test, known_good, failed, or archived. Exactly one revision per model is marked recommended, so three months later there is a single unambiguous answer at the top of the page. Known-good G-code revisions covers that workflow properly.

Since v0.11.0 the same vault feeds a fleet queue. Administrators queue G-code across configured printers using manual, default-printer, or deterministic least-busy routing, then reorder, reroute, cancel, and retry eligible failed dispatches. Immediate sends and scheduled dispatches share one transfer path, so capability checks behave identically whether a job runs now or in an hour. Printers can be put in soft-drain mode or given maintenance windows, and the scheduler dispatches around them, which beats taking a machine out of rotation by unplugging it. v0.11.1 added per-printer view, print, control, and admin grants on top.

Moonraker is the stable provider and gets the full capability set: live status, upload, start, remote file inventory, raw G-code, and measured filament consumption. PrusaLink, OctoPrint, Bambu LAN, and Elegoo Centauri are beta with narrower capabilities. The compatibility matrix is the current list, and it is worth reading before assuming an action exists for a given machine.

Where PrintStash stops

It is not an order system. There are no customers, quotes, due dates, or approval workflows, and nothing follows a job from a sales record through to shipping. O.D.I.N. is aiming at that space and PrintStash is not.

Failure detection is absent entirely. PrintStash has no camera analysis and will not pause a print that has turned into spaghetti, so it depends on the printer reporting an outcome. Klipper-side and OctoPrint-side plugins are where that job belongs.

Routing is deterministic and fairly blunt. Least-busy picks a free machine without scoring by loaded filament, nozzle, or plate compatibility, so a genuinely multi-constraint scheduling problem will outgrow it. Since v0.12.0 a preflight compares material and nozzle metadata before a direct send and flags a mismatch, which is a safety net rather than a scheduler.

Finally, each vault supports one API process. Startup claims a vault lock and refuses a second process because scheduling, rate limits, live printer state, and background registries are process-local. PostgreSQL does not change that deployment limit.

For the day-to-day operator view rather than the software selection, the print farm workflow guide walks through the job flow, and the small farm software stack covers how the pieces fit around Spoolman, notifications, and backups. If you want the selection question answered by bottleneck rather than by layer, the best farm software for Klipper is that shorter cut.

Questions that come up

Does this replace Mainsail or Fluidd?

No, and you should not want it to. Mainsail and Fluidd are per-printer control surfaces with macro buttons, config editing, and console access. PrintStash connects to the same Moonraker instance over its API and adds the library and the cross-machine queue. Both stay installed.

Can I send one G-code file to several printers at once?

Not as a single fan-out action. You queue the file and the router assigns it to a printer, so running the same part on six machines means six queued jobs. Least-busy routing spreads them as printers free up, and you can reroute or reorder anything still queued. Sending G-code to multiple printers from one app goes through this in detail.

What about printers that are not running Klipper?

They work, with narrower capabilities. Prusa MK4 and XL on stock firmware go through PrusaLink, anything already behind OctoPrint uses that provider, Bambu Lab machines in LAN mode can receive uploads and start prints but expose no file inventory, and Elegoo Centauri Carbon supports status, controls, and beta upload with no file inventory. All four are beta. A mixed farm works, but the Klipper machines will be the ones where everything is available.

Bambu farms have their own answer, because Bambu ships a free farm manager and the firmware actively restricts third-party control. Self-hosted print farm management for Bambu Lab printers covers that separately.

Sources