Local-first 3D print farm manager
PrintLan runs your whole mixed farm — Bambu Lab, Snapmaker, Qidi and any Klipper machine — entirely on your own PC and local network, and keeps it printing overnight with a queue runner that holds plates, checks filament, routes jobs and fans kit jobs out across machines. No cloud, no accounts, no per-printer fees — plus quotes, inventory, money reports and the real cost of every print.
The fleet wall
Live nozzle and bed temperatures, progress, layer counts, fan and speed levels, the running job's name — and per-tool filament swatches showing exactly which colors are loaded where. Printing machines sort to the top; printers group by model.
Thermals, progress, layer counts, fan and speed levels — plus true lifetime hour meters read from each machine's own counters, so hours and maintenance are real from day one. A 50-printer farm updates in about one printer's time.
On toolchangers the card shows which head is extruding right now; on Qidi's 4-lane filament box it reads the machine's own slot tracking — the ACTIVE marker is the printer's truth, not a guess.
One click from any card: camera, thermals, presets, jog and home, and a raw G-code console for full single-machine control when you want it.
If PrintLan doesn't know, it says offline — it never invents a status. One slow answer never flips a printer red; debounced, self-healing connections.
The killer feature
Send any sliced file to any printer and PrintLan makes it print right — matching is material-first, color second: a black PLA file can never auto-map onto a black PETG spool. You can change the color freely, never the material by accident. Wrong machines are flagged before anything moves, every guard can be rehearsed with zero risk, and a final Close enough check has the last word before anything reaches the machine.
FILE WANTS
SLOTS LOADED
Swap spools without re-slicing — the file's color order is rewritten in the G-code so white, black, red and amber land on whichever slots actually hold them. Colors remap freely; material never — PLA stays on PLA.
Slot matching is material-first, color second: a file sliced for PLA can only land on PLA slots. Slots holding the wrong material are shown but disabled — you change the color freely, never the material by accident — and a machine with no matching material says so plainly instead of guessing.
The G-code's color order is rewritten on the fly to match the spools that are actually loaded. AMS mapping for Bambu gets a slot-by-slot color check before anything is sent.
A file sliced for a 4-head machine won't silently go to a single-extruder printer. Profile and tool-count mismatches are flagged — and overridable only deliberately.
Bed leveling, flow calibration, timelapse — sent the way each manufacturer's firmware actually expects. We read Snapmaker's open-source firmware to get these right.
Rehearse the entire send — guards, mapping, prep — without starting anything. Test a new file on a farm mid-production with zero risk.
Bambu and Qidi .gcode.3mf multi-plate projects are handled natively — the correct plate is chosen automatically, metadata and thumbnails included.
"Slot 3 is loaded with blue but the file wants white." Send anyway is always your choice — the guard tells you exactly what's off before you make it.
Tick two machines or ten — review each one's slot mapping side by side and send to all, with a per-machine "send anyway" for deliberate color calls. Multi-machine sends carry each machine's own mapping, and direct prints can be tagged to an order at send time.
Overnight automation
Schedule jobs with start times and due dates; PrintLan dispatches them across the fleet and re-queues every copy of a batch automatically. When a machine finishes, the runner waits — tap "Plate cleared" (from the card or your phone's Discord ping) and production continues.
Kit & batch jobs
A 10-piece kit = 8 plates across 5 files: add a whole folder of sliced plates as lines in one click, pick a smart machine per plate — or let PrintLan choose by what's actually loaded — and the plates fan out in parallel. A live "plates done" chip tracks the job, and kit jobs only close when you close them: the software counts, it never decides a kit is done.
Self-healing network
Click Scan and PrintLan finds every printer on the network — including Bambus, which don't advertise like the others — identifies their models automatically, and adds a whole shelf of machines in a couple of clicks.
The party trick, now for every brand: printers get new IP addresses when they power-cycle. PrintLan notices the machine went missing, scans the network, recognizes it — Bambus by the serial number embedded in their security certificate, Klipper machines by MAC address — re-points it and reconnects automatically, usually within a couple of minutes. A manual reconcile now button is there for the impatient.
Cameras for every brand
Every printer's camera in the same dashboard: Bambu X1-series live streams, A1/P1 chamber cameras (we implemented Bambu's undocumented camera protocol directly — no ffmpeg needed on A1/P1), Snapmaker and Qidi webcams.
Cameras stream only while you're watching, and one polite shared stream per printer means adding viewers never multiplies the load on weak printer electronics.
A dead camera shows an honest "camera offline" tile instead of spinning forever. PrintLan keeps Snapmaker U1 camera sessions alive automatically — a stock-firmware quirk nobody else handles.
X1-series cameras need ffmpeg installed once — one winget command, and the app tells you exactly which. A1/P1 cameras and all Klipper-brand cameras need nothing extra.
Mid-print control
Pause, resume or cancel from any card or the console. A true emergency stop — hold-to-confirm, so it can't fire by accident.
The business layer
Other tools watch printers. PrintLan tracks the shop: every print is logged automatically with duration, grams, estimated vs actual time, status — and cost in real dollars. Even prints started at the printer, or ones that ran while your PC was asleep, are recovered from the printers' own job history.
Printer offline, firmware error codes decoded to plain meaning, structured machine exceptions, filament runout, stalls, missed prints, maintenance due — and machines paused too long get re-warned at 15 min, 30 min, then hourly. Pushed to your own Discord or self-hosted ntfy server. No cloud middleman.
Failed prints attach the evidence: the push carries the failure photo — "Print FAILED on Qidi Max 4 — order #104 at 43%, ran 96 min", picture included — so 2 AM failures are a glance, not a mystery. And the feed respects your attention: a printer flapping offline all night is one incident row with a hit counter, not forty alarms, with category chips (machines / print / spools / system) to keep it scannable.
Built farm-first
Every detail below exists because a 14-printer farm with customer orders — including overnight batches and multi-machine kit jobs — demanded it.
Upload files or link folders — they index themselves: slice into the folder and the file appears ready to print within a minute, metadata, colors and thumbnail included. Search by color, duplicate detection, collections, and an "On printers" view with pull-back — download the G-codes sitting on any machine. And before anything ships, Close enough — a final checker with the last word before a file goes to the machine.
24 parallel workers — a 50-printer farm updates in about one printer's time.
One stream per printer, fanned out to every viewer — weak boards are never hammered.
Dead machines are checked less often, so they never slow the live ones.
Debounced status — one slow answer never flips a printer to "offline". If it doesn't know, it says so.
Under the hood
PrintLan speaks to printers the way their own studio software does — Moonraker/Klipper HTTP APIs for Klipper machines, Bambu's local MQTT control channel, FTPS file transfer, RTSP and camera protocols for Bambus, SSDP + mDNS + network scanning for discovery. Field-verified against real printers, down to reading the printer model from the filename a slicer embeds in the G-code.
We reverse-engineer what vendors won't document — Bambu's A1/P1 camera protocol, their incremental status telemetry, the exact print-start payload their own studio sends, Snapmaker's firmware-gated calibration flags, and Qidi's filament-box state (which feeder slot is live lives in the firmware's saved variables — so "which slot is printing" is the machine's own truth). When a vendor changes something, PrintLan adapts — updates have shipped the same day.
speaks natively
"The same protocol layer Bambu Studio itself uses — reimplemented for the whole farm, and hardened on a live one."
Why PrintLan
Offline, on your hardware, for every brand you own — with the business math included.
| Capability | PrintLan | Cloud dashboards | Vendor apps | Per-printer web UIs | DIY spreadsheets |
|---|---|---|---|---|---|
| Runs entirely on your PC — no cloud | ✓ | ✗ | partly | ✓ | ✓ |
| No subscription, no account | ✓ | ✗ | ✓ | ✓ | ✓ |
| Works during an internet outage | ✓ | ✗ | partly | ✓ | ✓ |
| Mixed brands on one wall | ✓ | some brands | ✗ | ✗ | manual |
| Customers, quotes & orders | ✓ | ✗ | ✗ | ✗ | you build it |
| Real cost-per-print & tax export | ✓ | limited | ✗ | ✗ | you build it |
| Failure photos & time learning | ✓ | ✗ | ✗ | ✗ | ✗ |
| Material-safe dispatch — PLA never lands on PETG | ✓ | ✗ | own brand | ✗ | ✗ |
| Overnight queue runner — plate holds, stall watchdog | ✓ | ✗ | ✗ | ✗ | ✗ |
| Kit jobs fanned out across machines — closed by a human | ✓ | ✗ | ✗ | ✗ | ✗ |
| Maintenance schedules from true lifetime hours | ✓ | ✗ | ✗ | ✗ | ✗ |
| Profit & scrap-pile reports | ✓ | ✗ | ✗ | ✗ | you build it |
| Self-healing for every brand (serial + MAC) | ✓ | ✗ | ✗ | ✗ | ✗ |
vs vendor apps — Bambu Handy/Studio, the Snapmaker toolchain and QIDI Studio each see only their own brand, and none has the business layer.
vs per-printer UIs — Mainsail and Fluidd are one-printer dashboards; PrintLan is the shop dashboard above them, with full single-machine control still a click away.
vs DIY — you'd spend months building material-safe dispatch, automatic filament deduction with self-heal, failure timelines, time learning, run-sheet spool planning and serial self-healing — and they're already hardened on a live farm.
Setup & requirements
One double-click to start — start.bat installs its own dependencies on first run. Honest requirements, no asterisks.
A Windows 10/11 PC on the same network as the printers. First run installs everything it needs. Opens in Chrome, Edge or Firefox.
PrintLan finds every printer on the network and identifies the models automatically. Klipper machines (Snapmaker U1, Qidi, Voron…) need nothing special — optional API key supported. A whole shelf of machines joins in a couple of clicks.
Bambu's firmware requires you to opt in to local control, per printer:
PrintLan reads the serial automatically from the printer's security certificate (you never type it), verifies the access code for you, and warns clearly if Developer Mode is off — a printer that uploads but never starts is the classic symptom, and the fix is the toggle above.
Works out of the box too — including per-slot tracking of the Qidi filament box (which feeder is live, straight from the machine's own state) and true lifetime hour meters.
Windows 10/11 PC · printers and PC on the same local network — that's how it stays cloud-free.
Printers on a different subnet than your PC will show offline — a network fact, not a bug. Your PC is the brain today, so it stays on; a Raspberry Pi appliance is on the roadmap.
LAN-Only Mode is Bambu's own cloud opt-out: with it on, Bambu's cloud apps (like Bambu Handy) can no longer reach that printer. That's the point — everything local, PrintLan included, keeps working.
Roadmap
Deliberately not planned: no cloud, no accounts, no telemetry. That's the product.
FAQ
No. It works with the internet unplugged — it only needs your local network. The only thing that can ever leave your network is an alert you explicitly enable (Discord or ntfy push); control and data never do.
Yes — A1, P1 and X1 series. You enable LAN-Only Mode and Developer Mode once on each printer's touchscreen (Bambu requires this for any third-party control), and PrintLan handles the rest, including auto-detecting serials and self-healing IP changes.
It guards against that: profile, tool-count, color and slot checks run before anything is sent — and material is never auto-changed. A PLA job can't silently land on a PETG spool, even in the same color; you can always override the color deliberately, but moving the material needs a human and a physical spool swap. Single sends and multi-machine sends alike — and you can rehearse the whole send in dry-run mode first.
That's what the queue runner is for: scheduled jobs, batch quantities with automatic re-queuing, plate holds until you clear them, a filament pre-flight check, and a stall watchdog that raises an alarm instead of failing silently. When you come back, the welcome-back report lists everything that finished while you were away.
The machine finishes on its own. When PrintLan returns, it recovers the print from the printer's own job history — duration, outcome, cost — settles it against the order, and flags anything it couldn't verify for a one-tap decision. Machines that confirm their own finishes (Bambu) are trusted automatically; the log never invents an outcome.
Yes — kit jobs. Add a folder of sliced plates as lines in one click, fan them out across machines in parallel (each plate lands on a machine whose loaded material and colors fit), watch the live plates-done count, and close the job yourself when the assembly is done — the software counts, it never decides a kit is finished.
Yes — filament spools deduct grams automatically as prints finish, and finished goods track pieces per plate, sale price, cost to make (from the print's real tracked filament and machine time) and total shelf value.
It stays in files on your PC — an SQLite database and your own folders. Backups are a zip you keep. Delete them and it's gone; nobody else ever had a copy.
Today, yes — PrintLan is the brain. An always-on Raspberry Pi appliance is on the roadmap. And prints that ran while the PC was off are recovered into the log automatically when it returns.
Really. The current production install runs Bambu X1Cs and A1s, Qidi Plus 4s and a Max 4, and six Snapmaker U1s side by side — 14 machines, including unattended overnight batches and multi-machine kit jobs.
Closed machines that aren't Bambu and don't run Klipper — for example Creality's older stock firmware, or a Prusa without Moonraker. If it's a Bambu Lab printer or Klipper-based (Snapmaker, Qidi, Voron, RatRig, Prusa with Moonraker…), PrintLan runs it.
Pricing isn't announced yet. The promise: one low, flat price for your whole shop — the same whether PrintLan connects 5 printers or 50. Never per-printer, never a subscription: the software runs on your hardware, so more machines cost it nothing. Join the list to hear it first.
Early access
PrintLan is in daily production on a real 14-printer mixed farm — overnight batches and multi-machine kit jobs included — and we're opening it to a small group of print-farm operators. Every answer below goes straight to the roadmap — it decides what gets built next.
Prefer chat? Ask on Discord or email us.