What to look for in a self-hosted 3D manager

Most self-hosted model libraries look identical in screenshots: a grid of thumbnails, a sidebar of collections, a search box. The differences show up two weeks in, when you have thousands of files indexed and you try to answer a question the grid was not built for. These are the criteria that decide whether you keep using the thing, each with a test you can run against a trial instance before you commit a library to it.

This is a rubric rather than a shortlist. If you want the shortlist, the 2026 roundup covers who currently does what.

1. Does it understand G-code, or just store it?

The dividing line between a file manager and a print library is whether sliced files are first-class. A tool that treats bracket_0.16.gcode as a blob leaves you encoding settings in filenames again, which is the problem you were trying to leave.

Test it: upload a slice and see whether layer height, nozzle, material, temperatures, estimated time, and filament use appear without you typing them. Then upload a second slice of the same model and see whether the tool relates them or files them as two unrelated objects.

2. Are duplicates found by content or by name?

Every library over a few hundred files has the same STL under three names. Name matching finds none of those and flags false positives on unrelated parts that happen to share a name.

Test it: copy a file, rename the copy, and import both. A content-hash library recognizes them as the same bytes. Ask what happens on a near-duplicate too, since a rescaled or repaired mesh is a different file by hash and no tool can tell you it is “the same model” without guessing.

3. Does it move your files?

This is the question people skip and regret. Some tools import files into their own storage layout, some index them where they already sit, and the difference decides whether your slicer’s existing paths keep working and whether uninstalling costs you anything.

Test it: point it at a copy of a real folder, let it index, then look at the folder. Nothing should have moved or been renamed. Then remove a model from the library and check the disk again: removing an index entry should never delete source bytes that came from your own directory tree. Ask what happens when the mount disappears, too. A tool that reads an unmounted NFS share as “every file was deleted” can wipe an index in one scan.

4. Is the printer integration honest about what it cannot do?

Printer support is where marketing pages flatten five different protocols into one checkmark. What matters is per-provider capability: which machines can receive an upload, which expose the files already on them, and which report back what a print actually consumed rather than what the slicer guessed.

Test it: find the capability matrix before you buy into the workflow, and check your own printer’s row. If a tool cannot tell you which actions are unsupported on which provider, it has not thought about it. For reference, in PrintStash today Moonraker is the stable provider with the full set, and PrusaLink, OctoPrint, Bambu LAN, and Elegoo Centauri are beta with real gaps, listed on the compatibility matrix.

5. How hard is it to leave?

Assume you will migrate eventually, because you will. The exit path is a feature, and its absence is the most expensive thing on this list.

Test it: export the library before importing anything serious. Look for your metadata, collections, tags, revision history, and print history in a format you could read without the app, and for a full backup that includes the database and the files it owns. Then do the part almost nobody does and restore it somewhere else. A backup you have never restored is a hypothesis. Backups that actually restore covers what that rehearsal looks like.

6. Does the access model match your household?

Single-user tools are fine for single users. The moment a partner, a housemate, or a makerspace member touches the library, you need roles that the API enforces rather than buttons the interface hides, and a way to share one model with someone without giving them the library.

Test it: create a second, non-admin account and try to do something it should not be allowed to do, ideally through the API rather than the interface. Then create a share link and check whether it expires, whether it can be revoked, and whether it exposes downloads by default.

7. Will it run on the hardware you actually have?

A library that needs a real server is not a library you will run on the Pi in the cupboard. Check the architecture support, the memory floor, and what happens with large meshes specifically, because mesh rendering is where RAM disappears.

Test it: import your ten largest files, not your ten prettiest. Watch memory during the first index. Ask what is degraded on ARM: in PrintStash that gap closed in v0.12.0, which generates STEP previews on ARM as well, though the evidence is CI under emulation rather than a physical Pi.

8. What is unsupported in the formats you use?

Format support is rarely binary. A tool can parse a format’s metadata but not preview it, or preview it but not send it to a printer.

Test it: take one file of each format you actually use and check three things separately, which are metadata, preview, and printer send. PrusaSlicer’s binary .bgcode is the usual surprise: PrintStash reads its metadata and thumbnails but cannot render its toolpath or send it to a printer while the compressed body stays undecoded.

9. Is the project alive, and can you live with its license?

Self-hosting means you inherit the maintenance. Check the release cadence, whether issues get answered, whether the license permits what you intend, and how much of the project depends on one person. A young project moving fast can be the right choice, as long as you know that is what you picked.

Test it: read the last three release notes. They tell you more than the feature page, because they show what actually shipped, what broke, and whether migrations are handled carefully.

What people overweight

Thumbnail grids and dark mode. Every tool has them, they are visible in the first five minutes, and they have nothing to do with whether you can find a file in eighteen months.

Feature counts and roadmaps. A roadmap is a plan, not a capability, and comparing a shipped feature against a planned one is how people end up with a library that cannot do the thing they chose it for.

Print monitoring. It is worth naming that a file library is not a monitoring tool: no camera wall, no spaghetti detection, no per-machine dashboard for watching a first layer. Mainsail, Fluidd, and OctoPrint own that job, and the sensible setup runs both. If monitoring is the actual problem, solve it with a monitoring tool.

Questions that come up

What is the single most important criterion?

Whether you can get your data back out. Everything else is a preference you can live with or work around, but a library that holds your metadata hostage turns a bad fit into a migration project you keep postponing. Test the export and, more importantly, the restore before you commit a real library. The second most important is content-hash identity, because it is what lets a library survive years of renamed and re-downloaded files without silently accumulating duplicates.

Do I need G-code revision tracking if I only print occasionally?

Probably not at first. For twenty models printed a few times a year, filenames and a folder tree genuinely work, and any library is a convenience rather than a necessity. Revision tracking earns its keep when you reslice the same parts, run more than one printer, or share a library with someone else, because that is when “which file printed well” stops being answerable from memory. Picking a tool that has it costs nothing while you do not need it.

Should the library also control my printers?

It should be able to send a file and record the outcome, and it should not try to replace the controller. The valuable part is the link between a slice, a print job, and the result, since that is what a controller cannot store because it only knows filenames on one machine. Live control, webcams, terminals, and firmware work stay with Mainsail, Fluidd, or OctoPrint. Any tool claiming to replace all of it is either much larger than it looks or overselling.

How much does hosting one of these actually cost me?

In hardware, usually nothing you do not already own: a Pi, a NAS, or an always-on mini PC is enough for a personal library, with roughly a couple of gigabytes of RAM free if you index large meshes. The real cost is maintenance: container updates, a backup that runs, and a restore rehearsal once in a while. Budget an hour a quarter, and prefer a tool whose upgrade notes suggest the maintainer thinks about migrations.

Is a NAS folder plus good naming enough?

For many people, yes, and it is worth saying so. A consistent folder tree with disciplined names answers most questions for a library of a few hundred models on one printer. It fails on three specific things: identical files under different names, which slice printed well, and any question that cuts across the folder hierarchy. If none of those bite you, the extra service is not worth running.

Sources

• PrintStash compatibility matrix, capabilities, and known limitations for the specifics quoted above, including the ARM and BGCODE limits.

For how specific tools score against these criteria, the 2026 roundup is the survey and PrintStash versus the alternatives separates libraries from monitoring, remote access, and farm platforms. If the library is going to hold the only copy of anything, what production grade would actually mean is the durability half of the same question.