Self-hosted print farm management for Bambu Lab
Bambu Farm Manager, bambuddy, and multi-brand tools compared for a cloud-free Bambu farm, plus what the authorization control means for third-party tools.
A Bambu farm is a harder problem than a Klipper farm, and not because the printers are worse. Klipper exposes Moonraker, a documented API that anything can talk to. Bambu’s local protocol is unofficial, and since the authorization control system arrived the printer itself checks whether a command came from Bambu’s own software before acting on it. That single fact shapes every choice below.
If your farm is entirely Bambu, start with Bambu Farm Manager. It is free, runs on your own network, and does not fight the firmware. Reach for a third-party tool when you need something it does not do: running it on Linux, keeping a model library with slice history, or managing Bambu machines alongside other brands.
Tool details were checked against each project’s public pages on August 3, 2026. There are no sponsored placements or affiliate links.
The authorization problem comes first
Bambu’s authorization control system makes the printer verify that control commands originate from official or authorized software, and reject them otherwise. Bambu’s own announcement is blunt about the consequence: “Unauthorized third-party software will be prohibited from executing critical operations.” Restricted operations include printer binding, starting a print job, axis movement, and calibration. Monitoring survives, and the announcement confirms that reading temperature, position, and speed, plus LED control, stay accessible.
It landed on the X series first, with firmware 01.08.03.00 and above, and Bambu said P and A series updates would follow.
The practical escape hatch is Developer Mode, an option you enable on the printer that keeps MQTT and FTP open for local tools. Standard LAN mode alone generally leaves third-party software with read-only monitoring. bambuddy’s documentation states the split directly: Developer Mode is required for full control, and standard LAN Mode only permits read-only monitoring.
So before choosing any tool, decide whether you are willing to run your farm in Developer Mode. If you are not, your realistic options are Bambu’s own software or monitoring-only dashboards. Nothing below changes that.
Bambu Farm Manager, the default worth beating
Bambu ships a free farm manager, and for a Bambu-only farm it is the sensible starting point rather than a fallback.
It installs as a background server service plus a desktop client, runs entirely on the local network, and covers real-time monitoring, batch control across machines, job queuing based on printer availability, a central file repository with folders and tags, firmware updates over LAN, and multi-user access. It even staggers start times to avoid power spikes when a rack of machines begins at once. It supports the X1, P1, and A1 lines, and Bambu does not require Developer Mode for it.
Two things will decide whether it works for you. It runs on Windows 10 or higher, 64-bit only, with Linux and macOS planned but not shipped, which rules it out if your infrastructure is a Linux box or a NAS. Printers also have to be unbound from the cloud before you add them, and LAN Only Mode should be off during pairing, which surprises people who set their farm to LAN-only years ago and never touched it again. It also cannot split a single job across different printer models.
bambuddy, if you want it self-hosted and open
For a Bambu-only farm that has to run on Linux or in Docker, bambuddy is the strongest open-source option and it is not a toy. AGPL-3.0, roughly 2.7k GitHub stars, SQLite or Postgres, and installers for Docker, Windows, Linux, and macOS.
Its coverage is wider than Bambu’s own tool: X1 series including X1E, X2D, the H2 family, P1 series, P2S, and the A series. Feature-wise it goes further than dispatch, with a print queue with scheduling and multi-printer dispatch, a file and model library with 3D preview, integrated spool inventory, and optional server-side slicing through a sidecar container.
If you are running a Bambu-only farm on Linux and want a library and a queue in one self-hosted package, this is probably your answer, and it is a closer match to that job than PrintStash is. It needs Developer Mode.
Multi-brand tools that speak Bambu
Three of the tools from the Klipper farm comparison also handle Bambu machines, which matters when the farm is mixed.
| Tool | Licensing | Bambu transport | Holds a model library |
|---|---|---|---|
| FDM Monster | AGPL-3.0, free | Bambu LAN | G-code files and thumbnails |
| print-farm-manager | MIT, free | Bambu MQTT and FTPS | No, G-code dispatch only |
| O.D.I.N. | BSL 1.1, free for 5 printers and 1 user | Bambu MQTT (X1C, P1S, A1, H2D) | Not a documented feature |
| PrintStash | AGPL-3.0, free | Bambu LAN, beta | Yes, source meshes plus G-code revisions |
What PrintStash can and cannot do with Bambu
The Bambu LAN provider is beta, and its capability set is narrower than Moonraker’s. It shows live state, progress, and temperatures, uploads plain-text G-code from the library, starts the uploaded job when you explicitly ask it to, handles pause, resume, and cancel, and records the job in the model’s print history.
It cannot list or delete files already on the printer. In a farm that limitation compounds: with a dozen machines you have no central view of what is sitting on each SD card, so cleanup stays a per-printer chore. It also does not send arbitrary G-code, exposes no emergency stop, and receives no live extrusion measurement, so filament figures come from the slicer estimate rather than the machine. Spoolman consumption write-back remains Moonraker-only.
The fleet queue does work with Bambu, because queued dispatches run the same capability checks as immediate sends and Bambu supports both upload and start. You can queue vault G-code across Bambu machines with manual, default-printer, or least-busy routing, and put a machine into soft-drain or a maintenance window like any other. v0.11.0 also made Bambu MQTT commands wait for the printer’s own report before treating a print, pause, cancel, or resume as successful, instead of assuming the command landed.
Remote start is opt-in per send and PrintStash checks that the printer reports idle first. Whether start actually succeeds depends on your firmware version and how the printer’s LAN options are set, which is the authorization problem from the top of this article showing up in practice rather than anything specific to PrintStash. On a beta provider driving an unofficial protocol, leave start disabled until you have watched a few transfers land correctly, and check the printer’s Diagnostics tab when something is refused.
What works today in LAN mode has the current provider detail, and the compatibility matrix is the authoritative list.
Choosing
For a Bambu-only farm on Windows, use Bambu Farm Manager. For a Bambu-only farm on Linux or Docker that needs a library, use bambuddy. Both are better fits for those cases than PrintStash, and pretending otherwise would waste your afternoon.
PrintStash earns its place when the farm is mixed, or when the thing you keep losing is not the job but the history: which of the six slices of this part actually came out right, what the source mesh was, and what it cost. Bambu machines then sit in the same library and the same queue as Klipper builds and Prusa machines, at the capability level each provider supports. That mixed case is the one Bambu’s own tooling structurally cannot serve, because it only manages Bambu printers.
Sources
- Bambu Lab on the authorization control system.
- Bambu Farm Manager documentation.
- bambuddy (AGPL-3.0).
- FDM Monster, print-farm-manager, and O.D.I.N..