3D Print Farm Infrastructure: Fleet Management, Job Queue and Inventory

The server side of a 3D print farm is three independent layers: machine control (FDM Monster 2.1.1, Bambu Farm Manager 02.04 or Repetier-Server at €59.99), filament and inventory tracking, and a business layer for orders and costing. Only the first one has to live on the same network as your printers. The other two don't — and that single fact drives the whole architecture.

With two printers you keep everything in your head. At five it starts slipping — which one finished, which has black PETG loaded, which is down to 40 g on the spool. At fifteen you simply can't work without a single pane of glass; half your shift goes into walking the rows. This guide covers how to assemble the server side of a farm out of tools that are actually alive in 2026, instead of the dead projects that still rank on page one.

The three layers of a farm's server side

The classic planning mistake is treating "the farm server" as one program. In practice it's three layers with different hardware needs, different network needs, and different answers to the question of where the box physically sits.

The split isn't academic. The control layer holds a live connection to every machine: a socket for OctoPrint, Moonraker polling for Klipper, an MQTT channel inside the LAN for Bambu Lab. None of that survives being moved to a rented box in another datacenter, and none of it gets more reliable for the trip. Inventory and orders, on the other hand, are perfectly happy somewhere else — and are usually better off there.

What you'll need

• A host for the dashboard on the printers' network: a Raspberry Pi 4 or 5, a mini PC, or a VM. FDM Monster runs on 512 MB of RAM minimum, 2 GB+ recommended, and 500 MB – 1 GB of disk
• Wired networking to that host, and to the printers wherever the vendor allows it — a switch is cheaper than any downtime
• A DHCP reservation for every printer, or half the fleet moves addresses after the next router reboot
• Printer credentials: an API key for OctoPrint, host and Moonraker port for Klipper, access code plus serial number for Bambu Lab in LAN mode
• A number for how many amps your circuit actually carries — simultaneous bed heating is the number one cause of a tripped breaker on a farm
• Off-site space for backups: fleet database, G-code library, order records
• Real ventilation — emissions from fifteen machines stack up, see our guide to 3D printing fumes and extraction

Fleet management software that's actually alive in 2026

This niche is thinner than you'd expect. There is exactly one fully open-source fleet manager under active development — FDM Monster. Everything else is either closed vendor software, a paid service billed per printer, or an abandoned project that still owns the top search results.

FDM Monster — the one open-source option still shipping

FDM Monster grew out of OctoFarm — it split off in September 2021 once it was clear the original codebase couldn't be salvaged without a rewrite. Today it sits at 182 GitHub stars under AGPL-3.0, with commits on the main branch as recent as August 1, 2026 and the latest release 2.1.1 from May 14, 2026. The star count is modest, but this is a niche tool for farm operators, not a library everyone imports.

Storage is SQLite baked into the app — no separate database server, and MongoDB support was dropped after 2.0, which is a simplification rather than a loss. Requirements are tiny: the docs say 512 MB of RAM minimum, 2 GB recommended, and 500 MB – 1 GB of disk. It runs on x86-64, ARM64 and ARMv7, so a Raspberry Pi 3B+, 4 or 5 all qualify.

• Four printer types in one window: OctoPrint, Moonraker for Klipper, PrusaLink and Bambu Lab in LAN mode
• Printers arranged on floors and a configurable grid — you can mirror the actual shelving layout
• Batch printing: select several printers, send one file to all of them
• Drag a G-code file straight onto a printer tile to start it
• Mark a printer as under maintenance — still visible, receives no jobs
• Import printers from OctoFarm, so migrating isn't a from-scratch job
• Export and import the whole fleet config as YAML: a snapshot before an experiment takes seconds
• Prometheus metrics at /metrics once you set ENABLE_PROMETHEUS_METRICS

What it deliberately isn't: no cloud, no phone app, no AI failure detection, no customer-facing reports. It's a control room, not a business system — and that focus is the point.

What happened to OctoFarm, and why you shouldn't build on it

For years OctoFarm was the default answer to "how do I manage a farm of OctoPrint instances?" Now it's a trap. The last commits landed on May 19, 2023 — over three years of silence. Back in April 2023 the FDM Monster author put it plainly: "OctoFarm has stalled in development completely."

While you're at it, cross FarmPi off the list too — the Raspberry Pi image that shipped OctoFarm alongside several OctoPrint instances. The repository was archived by its owner on February 7, 2024 and is read-only. Its capacity table is still a useful reference (more on that below), but don't flash the image: OctoFarm is still inside it.

Bambu Farm Manager — for an all-Bambu fleet

Bambu Lab has shipped its own free fleet tool since May 27, 2025, and it has matured noticeably over the past year. It's two pieces: Bambu Farm Manager Server, a background service that talks to the printers, and Bambu Farm Manager Client, the operator window. Several clients with different roles attach to one server, so a shift can work together.

As of August 9, 2026 the current builds are server 02.04.00.03 and client 02.04.03. Coverage is close to the full lineup: H2C, H2D, H2D Pro, H2S, X2D, X1C, X1E, P2S, P1P and P1S, A1 and A1 mini, A2L. Each model has a firmware floor — X1C from 01.09.00.00, P1P and P1S from 01.07.00.00, A1 and A1 mini from 01.04.00.00, H2D from 01.02.00.00. With older firmware the printer simply won't be added.

• Windows 10 or newer on a 64-bit x86 CPU only — no Linux, no macOS
• Printers join the network over 2.4 GHz Wi-Fi; the server must sit on that network or be routable to its subnet
• The client needs internet access for server activation, printer verification and firmware downloads — a fully air-gapped install isn't possible
• Commands and files only travel inside your LAN over an encrypted channel; nothing routes through the cloud
• Files must be gcode.3mf exported from Bambu Studio, max 20 per upload, single plate per file
• "Direct To Print" only offers idle printers whose model and nozzle diameter match the sliced file
• Machines are grouped with tags; mass operations run through Bulk Action
• Staggered print start is built in to avoid power spikes; the A1 mini is exempt thanks to its low draw

Prep before adding a printer: update the firmware, unbind it from Handy so the account shows "Logged Out", and turn LAN Only mode off. That last one trips everyone up — intuition says the opposite, but Farm Manager reaches the machine over the vendor's own authenticated channel, not the one third-party tools use.

One detail worth calling out from the file view: Bambu Studio embeds the printer model, nozzle diameter, plate type and temperature, print duration and filament usage into the gcode.3mf. The wiki example shows a P1P, 0.4 mm nozzle, textured PEI plate at 65 °C, 48 minutes and 11.76 g of PLA. That's exactly why the software can filter out incompatible machines — it reads the file instead of guessing.

Repetier-Server — paid, but grown up

Germany's Repetier-Server is the case where money buys predictability. The free edition handles up to two printers, Lite at €29.99 up to five per install, and Pro at €59.99 removes the limit entirely. One-time payment, no subscription. The free edition carries one extra caveat: its print preview only renders the first 25% of the model.

Three things matter for a farm. First, Repetier-Server Monitor: a free desktop app for Windows, macOS and Linux that merges several Pro installs into one window — the docs screenshot shows Mini, Z-Belt and Delta from a single host, with a placeholder where a printer has no camera. Second, the queue with repeats: set a copy count per job and reorder by dragging. Third, the shared G-code directory: for identical printers you pick "use files from printer X" in settings, so a file doesn't have to be uploaded to each machine separately.

Prusa Connect and the cloud services

An all-Prusa farm may not need a separate manager at all. Prusa Connect is free for Prusa owners and includes 1 GB of cloud storage for G-code and telemetry. Local PrusaLink is built into CORE One, XL, MK4 and MK4S, MK3.9, MK3.5, the MINI with a Wi-Fi module, and the SL1 resin machines — only the older MK3 and MK2.5 still need an external Pi. The obvious catch: one vendor only.

Paid cloud platforms — SimplyPrint, Printago, AutoFarm3D — tie price to fleet size. SimplyPrint is free for two printers, and its Print Farm plan runs $39.99/month with ten printers included; beyond that you buy add-ons. You get ready-made storefront integrations and AI failure detection in return, but the bill grows with the fleet. The math is simple: a dashboard on hardware you already own costs electricity.

Installing FDM Monster: three routes

All three are equivalent; only the update workflow differs. Docker if the host already runs other things, the install script if the box is dedicated to the dashboard, the MonsterPi image if you've set aside a Pi for it.

Step 1. Docker Compose

Usual routine: docker compose up -d, dashboard at http://localhost:4000. Both volumes matter — /app/database holds the SQLite file with your entire fleet, /app/media holds logs and uploaded files. Skip them and the next image update takes your printer configuration with the container.

Step 2. One-line install on Linux

The script advertises Ubuntu, Debian, Fedora, CentOS, Arch "or similar". It wants Node.js 24+ and installs it if missing. The service registers with systemd, same port 4000. Standard advice for any curl-to-bash installer: open the script and read it before you run it.

Step 3. The MonsterPi image

MonsterPi is a Raspberry Pi OS Lite image with FDM Monster preinstalled, built with CustomPiOS. It supports the Pi 3B+, 4B+ and 5 and flashes with the standard Raspberry Pi Imager. After boot the dashboard answers at http://monsterpi.local:4000, and also on http://monsterpi.local and https://monsterpi.local — the latter with a self-signed certificate, so expect a browser warning.

Step 4. First login and the environment variables that matter

First load walks you through a wizard and asks for an admin account. Login is required by default and self-registration is off; both are switchable. Here's the shortlist that actually comes up on a farm.

Connecting all four printer types

OctoPrint

The best-tested path. Four fields: name, IP or FQDN, port, API key. If the browser doesn't show a port, it's 80 for http or 443 for https. The key comes from OctoPrint's user settings, Access tab. Hit "Test connection" and the dashboard runs five checks in sequence — API responding, socket opening, socket opened, socket authenticating, socket authenticated. One red light and the printer won't save.

Klipper via Moonraker

Klipper support landed back in 1.7.0 and spent a long time as a manual opt-in: cogwheel → experimental menu → "Enable Experimental Moonraker Support". The developer announced in December 2024 that Klipper and Moonraker should be on by default, and in February 2025 moved that to 2.1. But the issue is still open and the target version in its body is struck through, so on 2.1.1 the toggle may well still be there. Practical advice: if a Moonraker printer won't add, check the experimental settings. The printer itself is defined by host address and Moonraker port — 7125 unless you changed it.

PrusaLink

Prusa machines with built-in PrusaLink connect as their own printer type, which is handy for a mixed shop: the Prusas join the same dashboard as your Klipper and OctoPrint machines and you don't need a second tab open on Prusa Connect. One caveat: PrusaLink uploads are being fixed right now — pull request #5405, opened July 25, 2026, primes Digest authentication before the upload stream and returns failed jobs to the queue instead of dropping them. It hasn't been merged, so the released 2.1.1 doesn't have the fix. If your farm is mostly Prusa, verify file upload end-to-end before moving production onto the dashboard.

Bambu Lab in LAN mode

The rawest of the four — the project's own FAQ marks Bambu Lab support as "in progress". The printer connects through LAN mode: enable LAN Only on the machine's screen, then Developer Mode, after which third-party software needs the address, the access code shown on screen and the serial number. Developer Mode opens the MQTT channel, the live stream and FTP — in the official wiki's words, "full control over your printer and its network security".

An honest read on maturity: an unanswered bug from April 30, 2026 reports that saving a P1S returns a 500 with a connection refused on port 2024, and issue #4964, open since January 29, 2026, says Bambu printers don't report target temperatures. If your fleet is all Bambu, the vendor's own Farm Manager or Bambuddy is the more honest recommendation, and FDM Monster earns its place on mixed fleets.

Floors and grid: laying out forty printers without losing track

FDM Monster groups printers into "floors", which is its word for any logical cluster: an actual floor, a room, a shelving unit, a production line. One is created automatically on first run; you add the rest in settings. Inside a floor you drag tiles around with relocate mode on until the on-screen map matches the room. Grid size is set by row and column count, and a large-tile mode trades printers-per-screen for detail-per-printer.

The payoff is mundane and real: when the screen matches the shop floor, an operator walks to a position instead of reading name tags. The dashboard also nags when you forget one — a banner reading "Drag N unplaced printer(s)" appears with the names attached. In the printer list, watch the socket update column: a healthy machine reports in fractions of a second, a lost one shows "No update received (silence)", which is your first hint to go check the network or the power.

Job queues: what works today and what doesn't

"Queue" means two different things on a farm: a queue inside one printer, and distributing jobs across free machines. The first has been solved for years and costs nothing. The second is still nobody's.

Moonraker's built-in queue

Every Klipper printer already has a queue — the [job_queue] component in Moonraker, four lines of config away.

automatic_transition is the one that matters. It defaults to off, so the queue pauses after every job — correct behaviour while a human clears the bed. Turn it on only for a belt printer or a machine that clears itself, otherwise the next print starts on top of the last one. The transition delay and gcode exist precisely so you can slot ejection and a cooldown in between. One subtlety from the docs: when the queue picks a job up via load_on_startup, neither the delay nor the transition gcode is applied — don't count on a pause after a Klipper restart.

The whole queue is exposed over HTTP, so building automation on top of it is straightforward:

Two practical notes. The same filename can be enqueued repeatedly — that's how you set a batch size. And the whole request is rejected if any file in the list is missing on the printer; there's no partial enqueue, which is a feature: you won't quietly come up five parts short on a run of twenty.

Batch printing in FDM Monster

At fleet level FDM Monster solves the most common production task: select printers, push one file to all of them. That's replication rather than scheduling — but replication is exactly how a batch gets printed on identical machines. You can also just drag a file onto a printer tile. Bambu Farm Manager does the same in its own way: the wiki screenshot shows P292 and P496 from one group preparing the same 3DBenchy simultaneously.

What no open tool does yet: automatic routing

Every farm operator's dream is dropping a file in a folder and having it land on a suitable idle printer. As of August 9, 2026 no open-source tool does this. In FDM Monster it's open issue #5290, filed May 18, 2026, and the write-up is refreshingly blunt: a file arriving in the system lands in a shared library with no printer attached, and a human assigns the machine. Verbatim: "With multiple printer models, or a farm, it's the main friction point: nothing tells FDMM that a given gcode was sliced for a Prusa Mini vs a Voron."

The proposed design — a watched folder whose subfolders map to printer groups, routing to a group rather than a specific machine — is still just a proposal. Bambu Farm Manager gets closest: it reads the printer model and nozzle diameter out of the gcode.3mf and only lists compatible machines. But even there a human picks, just from a pre-filtered list.

How many printers per host

The classic cost question: one Pi per printer, or several printers per box? The answer depends on whether you're optimising for money or for risk.

Multiple Klipper instances on one machine

Klipper supports several instances on one host out of the box. KIAUH makes it painless: during install it asks how many instances you want, you name each machine, then you install the same number of Moonraker instances. Ports are assigned in sequence — 7125, 7126, 7127 and up — and that's how each printer gets added to the dashboard.

The manual part is splitting paths in printer.cfg. Each instance's [virtual_sdcard] and [save_variables] must point at its own directory, or two printers end up writing to the same variables file and reading each other's state. One more KIAUH limitation: it won't offer to add instances after the initial install, so you're either reinstalling or finishing by hand.

If you'd rather not run a fleet manager at all, a small Klipper farm can get by on the web interfaces themselves. Mainsail keeps a printer list in its interface settings — add hostname and Moonraker port, switch between machines, and there's a farm overview mode. Fluidd does the same and fully reinitialises on switch, pulling the new printer's settings and auth; you can bookmark a specific printer via the ?printer= query parameter. Both are healthy projects: Mainsail v2.18.2 from July 5, 2026, Fluidd v1.37.3 from July 20, 2026.

How much one Pi actually carries

There aren't many published Klipper benchmarks, but the capacity table from the archived FarmPi image survives. It's about OctoPrint instances, but as an order-of-magnitude reference it still holds.

Those numbers look generous, and there's a catch: they describe what the process survives, not what's sensible to trust to a single box. Klipper is also hungrier than OctoPrint since it computes motion on the host rather than on the printer's board, so halving them is prudent. That's an estimate from the shape of the workload, not a benchmark — no published Klipper figures exist.

Power: the constraint everyone plans last

Software scales for free; outlets don't. A typical desktop printer sips power in steady state but throws a spike during bed heating that dwarfs its running draw. Owner measurements from the Bambu Lab forum lay it out.

So here's the arithmetic. A 220 V circuit on a 16 A breaker nominally carries about 3.5 kW. In steady state that's a lot of machines — twenty at 150 W each. But if ten of them start heating beds at the same moment you're into kilowatts and the breaker goes. Forum members put it directly: ten machines per circuit is fine if you stagger the heating, and with simultaneous heating "you will trip the CB for sure". On 110 V the numbers are half as forgiving: consensus is four printers on a 15 A circuit, and five or six on a 20 A — with forum members themselves advising you stop at five.

The fix is called staggered start: jobs across a printer group begin with an offset rather than in unison. Bambu Farm Manager has it as a checkbox on the server activation page, and notes there that the A1 mini is exempt from the synchronised bed heating limit because it draws so little. On Klipper the job belongs to Moonraker's [power] component, which drives smart plugs and understands print context.

The pairing of on_when_job_queued and locked_while_printing is why you bother on a farm: a printer wakes itself when work appears, and nobody can cut its power mid-job. Supported plug types are plentiful — tasmota, shelly, tplink_smartplug, homeassistant, hue, smartthings, mqtt, uhubctl, plain gpio and a generic http option.

Networking: fixed addresses and why 2.4 GHz hurts

The dashboard reaches printers by address. If those addresses come from a dynamic pool, half the fleet lands somewhere else after a router reboot and the board fills with dead tiles. Reserve an address per printer on the router — fifteen minutes once, a permanent class of problem gone.

A Bambu-specific wrinkle: Farm Manager's requirements state that printers join over 2.4 GHz Wi-Fi. That band is slow and crowded, and twenty machines on one access point is a genuine load. Spread printers across several APs and keep them off the same network as your camera system. Where the vendor allows a cable, run a cable — the dashboard holds persistent connections to every machine, and a dropped link looks to the operator exactly like a lost printer.

Farm Manager's server and client may sit in different subnets as long as they're routable to each other — the vendor explicitly allows this and offers printer discovery over a supplied IP range rather than just the local subnet. For a shop split across two network segments that's the difference between working and not.

Filament tracking: what's left on the spool under printer 12

A fleet manager knows about jobs and nothing about material. On two printers that's tolerable; on fifteen it's straight loss — a spool runs out mid-way through an eight-hour print because nobody tracked the remainder. Spoolman covers this: a standalone inventory service that hooks into Moonraker and OctoPrint and decrements grams as you print. We covered installation separately; the architectural point here is that one Spoolman serves many printers, which makes it the obvious candidate to move off the farm onto a shared server.

Tracking pays for itself fastest once you buy in bulk: with thirty spools of the same PLA from different production lots, the shade difference between the start and end of a run gets discovered by your customer. And since material arrives by the box — don't skip drying: an opened spool sitting on a shelf picks up moisture within days.

Monitoring and failure detection

Cameras on a farm aren't decoration — they're how you avoid printing spaghetti for eight hours. Fleet managers show you the picture but don't understand it. Detection is a separate layer; how to self-host it is covered in our piece on running your own Obico server. One number from there matters for planning: the Obico server needs at least 4 GB of RAM, so it won't share the little box running your dashboard.

Bambu Lab runs its own detection on the printer itself, with a caveat straight from the official wiki: in LAN mode, cut off from the cloud, the machine relies only on the detection model baked into its current firmware, which can lag behind the cloud-updated one. For a farm sitting in LAN mode for privacy reasons that's an argument for keeping firmware current — though not by updating every machine on the same evening, as the next section explains.

And the boring part that stops being boring at scale: maintenance. A single printer forgives a skipped service interval; a fleet doesn't, because a clogged nozzle on one machine out of twenty goes unnoticed until end of shift. That's what the "under maintenance" flag in FDM Monster is for: the printer stays on the map but stops receiving jobs. What to check and how often is in our maintenance schedule.

When the server side outgrows the farm

Stated plainly, because the internet usually sells the opposite: you cannot move the fleet dashboard to a rented server. It holds live connections to printers over the local network, and from another datacenter there's simply nothing for it to talk to. No amount of hosting makes machine control more reliable — only longer.

Everything around the machines, though, genuinely wants its own server — not for convenience, but for specific reasons:

• Off-site backups. The fleet database, G-code library and order records live on the same card as the dashboard. Fire, flood or a dead SD card takes them along with production. The copy has to be in another building
• Multi-site inventory. A farm split across two rooms or two cities can only share Spoolman and stock records on neutral ground
• Taking orders. Customers need an address that answers around the clock, including when the shop loses power
• Metrics history. Prometheus and a year of graphs mean disk and constant work you don't want on the box responsible for printing
• Failure detection. An Obico server wants 4 GB of RAM, which your dashboard host almost certainly doesn't have spare
• Outside access. Checking on the farm from home is easier through a dedicated entry point; the methods are in our remote access guide

Requirements for that box are modest. Spoolman, a TLS reverse proxy and backup storage sit comfortably on 2 GB of RAM and 30 GB of disk. Add a full ERP with PostgreSQL or a failure-detection server and you want twice the memory. Included weekly backups matter more than an extra core here: the whole point of this machine is that it survives what the farm doesn't.

The business layer: when the spreadsheet gives up

Five orders a week fit in a spreadsheet. After that it's which part belongs to which order, how much material went in, what's been paid. Enter FilaOps, an ERP written specifically for print farms. It's young: created December 6, 2025, 75 stars, latest release v4.1.0 on June 20, 2026, main branch commits as recent as August 4, 2026. It advertises 48 features across eight modules — quotes and sales orders, invoices with PDF templates, customer payment terms and credit limits, multi-location inventory, spool tracking by weight, cycle counting, and production orders moving from draft through released and in progress to complete.

Under the hood it's Python and FastAPI with a separate frontend and a mandatory PostgreSQL 16 or newer — a real database server, unlike FDM Monster's single SQLite file. It runs via docker compose, but production startup deliberately refuses to boot until SECRET_KEY and DB_PASSWORD are set, so nobody ships a system full of customer orders on default credentials.

Don't mix up the layers: FilaOps counts money and stock, it doesn't drive printers. Its "Printers & Fleet" module advertises multi-brand management, MQTT monitoring and maintenance scheduling, but that's a record about a machine, not a control room. It doesn't replace the dashboard. And before building any accounting on top, get the underlying arithmetic right — see how print cost is actually calculated, or the system will neatly total up wrong numbers.

Backups: what to save first

1. Fleet configuration. In FDM Monster that's the YAML export straight from the printers page — keep a fresh one before every upgrade. Plus the fdm-monster.sqlite file itself
2. G-code library. Dialled-in production files represent hours of work that re-slicing won't reproduce exactly
3. Klipper configs. Each instance's printer.cfg with all its tweaks and calibration values
4. Inventory database. Spools, remaining weight, consumption history
5. Orders and customers. The one thing nothing can reconstruct

The rule is simple: a copy on the same SD card is not a copy. A copy in the same room is half a copy. And test a restore at least once — backups nobody has ever unpacked have a habit of turning out empty on exactly the day you need them.

Gotchas worth knowing up front

Everything below is an open item in the FDM Monster tracker, status verified August 9, 2026. None of it is a reason to skip the software — it's a map of where it stumbles.

What the server side actually costs

Counting only the infrastructure, not the printers or the material. The FDM Monster dashboard is free and runs on hardware you already own. Bambu Farm Manager is free but needs a dedicated Windows box. Repetier-Server Pro is a one-time €59.99 for five installs with no printer limit. Cloud platforms charge per printer per month, which on a fleet is the fastest-growing line on the sheet.

The external box for inventory, backups and order intake is the only recurring charge in this architecture. Size it by workload rather than by brochure:

For scale: one machine out of fifteen sitting idle for a day costs more than a year of hosting for the inventory box. The investment doesn't pay for itself through savings — it pays for itself by making downtime visible.

The part software can't fix

In June 2026 a post from a small basement farm operator went around r/3Dprinting: he's shutting down over lung problems, and notes he printed nothing but PLA. It collected over 2,700 upvotes and 1,500 comments. It's one person's account, not a medical finding, and should be read as such. But the reminder holds: fifteen machines in one room produce fifteen times the emissions of one, and ventilation is usually the last thing planned — after the electrics are sized and the shelving is bought.

The grown-up version of this conversation — concentrations, filter types, air changes per hour — is in our guide to 3D printing fumes and extraction. Plan extraction alongside the electrics, before the first shelf goes up.

Day-one checklist

1. Reserve a fixed address for every printer on the router
2. Stand up FDM Monster on a dedicated host on the same network and change OVERRIDE_JWT_SECRET
3. Add the printers and confirm all five connection checks pass on each one
4. Lay out the floors so the screen matches the physical rows
5. Export the fleet config to YAML and put a copy off-site
6. Count how many machines hang off each circuit and configure staggered start
7. Stand up filament tracking and load your current stock into it
8. Verify extraction works with every machine running, not just one

Sources

• FDM Monster documentation — installation, environment variables, floors and grid, metrics
• FDM Monster repository — releases, feature list, issue tracker
• Bambu Lab wiki: Bambu Farm Manager — requirements, supported models and firmware, setup order
• Bambu Lab wiki: third-party integration — what Developer Mode grants and what it costs
• Moonraker documentation — the [job_queue] and [power] components
• Repetier-Server version comparison — Free, Lite and Pro limits and pricing
• Prusa Knowledge Base — Prusa Connect versus PrusaLink
• BIGTREETECH wiki — multiple Klipper instances on one host with KIAUH
• Bambu Lab forum thread — measured power draw and printers per circuit
• FilaOps repository — print farm ERP, licence and requirements
• FarmPi archive — the Raspberry Pi capacity table