Print farms

3D model library management for print farms

By Petros, who builds Meshory · Updated Oct 11, 2026 · 9 min read

A print farm runs on two systems that get confused for one. Farm management software operates the machines: queues, job routing, printer assignment, orders, G-code. A model library manager answers a different question entirely, which is what you own, where it is, and which of the six copies is the one you print. Farm software is largely silent on that second question, and the bigger the library the louder it gets. This page sets out which layer covers what, and is specific about where Meshory stops, because it is a library tool and not farm management software.

Two layers, and only one of them is about printers

PrintStash, a self-hosted farm tool and therefore not a neutral party either, draws the split in its own August 2026 comparison: a file manager is "a library layer above the machine", and "the printer fixes which software controls the machine; it does not fix where your models, G-code revisions, and print history live". That is the distinction worth holding onto while you evaluate anything in this space.

Most farms end up running one of each, which is the right answer rather than a compromise. The mistake is expecting either one to cover the other half.

The library problems farm software leaves alone

These get worse with scale, which is why they bite farms harder than hobbyists.

The same part, saved six times, under six names

A farm accumulates duplicates faster than anyone: re-downloads, a kit bought twice in different bundles, a part re-exported at a different scale, the same model converted from STL to 3MF for a different printer. Most tools that claim duplicate detection hash the file bytes, which catches a renamed copy and misses every one of those, because a re-export shares no bytes with its original. Matching the mesh itself is what closes that gap, and hash vs. geometry-aware detection works through exactly which copies each method finds.

A library you cannot see

Farm software shows you the files you have already pushed into it. It does not render a preview for the 40,000 models sitting on the NAS that nobody has touched since the Kickstarter arrived, and an operator who cannot see a model will re-download or re-buy it rather than dig. Thumbnails across the whole archive are the cheapest fix for that, and the one farm tools are least likely to include.

Bundles nobody ever extracted

Creator and Kickstarter drops arrive as ZIP, RAR and 7Z and sit unopened, which means their contents are invisible to search and to any duplicate check. Reading inside archives without extracting them is the difference between a library you can search and one where a meaningful share is a black box.

A mixed fleet means mixed project files

A farm running Bambu alongside Creality or Snapmaker ends up with slicer projects that only open in the slicer that made them. Meshory's 3MF converter, in beta under Tools, moves a Bambu Studio, OrcaSlicer, Snapmaker Orca, Creality Print, Anycubic Slicer Next or PrusaSlicer project to one of the others as a new 3MF, with plates and painted colours carried across and the original left untouched. Since Meshory 1.10.0, the print settings you changed come across too. PrusaSlicer is the exception. Its projects do not record which settings you changed, so a conversion to or from it uses the destination's print profile, and because Meshory exports a PrusaSlicer project as one bed, only a one-plate project converts to it.

What Meshory does for a farm

One job, at the scale a farm actually has. It indexes folders in place on macOS, Windows and Linux, including NAS and network shares, and moves nothing.

• Every model visible: automatic thumbnails for STL, 3MF, OBJ, FBX, GLB, PLY, STEP, Rhino 3DM, Fusion F3D/F3Z and Lychee LYS (experimental), and a real 3D viewer including multi-plate Bambu projects.
• Duplicates found four ways: file content, mesh geometry, whole folders and folder overlap, so a re-export or a format conversion still groups with its original, a folder holding the same set of models collapses into one finding, and one bundle sitting inside another is reported rather than missed.
• Archives read in place: ZIP, RAR, 7Z and TAR/TGZ browsed like folders, with every model inside getting a thumbnail and counting toward duplicate detection.
• Search, tags and collections across the whole library, with optional AI tagging through your own provider account or a local Ollama model, never through a Meshory server.
• Straight into the slicer: 16+ installed slicers auto-detected, one click from the library, plus the 3MF converter for a mixed fleet.
• A licence key, no account: one licence is active on up to 5 workstations at a time; a farm that needs more can email support@meshory.com and we'll raise the limit.

On scale, a number rather than an adjective: it was built and hardened against a 118,270-model, 3.5TB library on one NAS share before it shipped, and scanning a NAS folder covers how network sources are handled.

What Meshory leaves to farm software

• No printer control: it does not connect to printers, dispatch jobs, schedule production or monitor anything. Its Print queue, added in Meshory 1.11.0, is a maker's to-print list: named batches for a market or a gift run, each with an optional due date, and a board with a lane for each printer you add by hand or from your slicer's presets.
• No orders, SKUs or customers: there is no product catalogue and no link between a model and a thing you sell.
• No G-code tracking: it does not version G-code, store known-good G-code against a model revision and profile, or parse slicer settings back out of a sliced file.
• No job records from the printers: nothing is read back from a printer. On a print list you mark each print printed or failed yourself, and the time and filament figures are estimates, saved by the slicer, worked out by OrcaSlicer or typed in by you, not measured use. Filament can be assigned to a model, and spool tracking is on the roadmap rather than shipped.
• No accounts, permissions or audit trail: it is a single-user desktop app. Several people can each run it against the same NAS share, but there is no shared state between them, no roles and no record of who changed what.

Those are farm management jobs, and farm software runs beside a library rather than replacing it. The table at the top sets out which system does what, and the comparison page sets Meshory against folders, model websites and self-hosted servers.

What farm management software covers

Printers, queues and orders belong to this layer, and each of these tools covers some part of it.

How the two layers fit together

1. 1The library lives where it already lives, on the NAS or the shared drive. Nothing gets migrated into a new home.
2. 2A library manager indexes it in place, renders previews, and clears the duplicates before anything downstream has to deal with them.
3. 3An operator finds the model, converts the project if the target printer needs a different slicer, and opens it in the slicer.
4. 4Farm software takes it from there: slice, queue, route to a printer, record the outcome against the order.

Deduplicating first is worth doing in that order. Every duplicate you carry into a production system becomes a duplicate SKU, a duplicate job or an operator printing the wrong revision.