Is there a better Moonraker file browser?

Two complaints hide behind this question, and they have different answers.

If the browser itself is what annoys you, because uploads are awkward or you cannot find a file three folders down, then you want a different Moonraker front-end. Fluidd and Mainsail both talk to the same Moonraker API, and their file managers are not the same product. Switching is a compose change or a KIAUH menu item, so try that before anything else.

If what you want is to know which of four files called bracket.gcode actually printed, or to get from a slice back to the STL it came from, no Moonraker front-end will take you there. That is not an interface problem. Moonraker’s gcodes root only lists sliced output, and its print history stores a filename. The information you are asking for was never recorded, so no amount of better browsing will surface it.

Name the wall before you go shopping.

What Moonraker’s file manager actually is

Moonraker exposes a filesystem. The file manager API serves a set of roots, of which gcodes and config are writable and logs, config_examples, and docs are read only. The gcodes root filters by extension, accepting .gcode, .g, .gco, .ufp, and .nc. An STL or a 3MF is not something it can show you at all. So it is a browser for slicer output by design, and judging it as a failed library misreads what it was built for.

It does parse a lot of metadata out of each file: object height, layer height, nozzle diameter, filament type and weight, estimated time, first-layer temperatures, and thumbnails. The documentation is direct about where that comes from. “Metadata field availability depends on the Slicer application and its configuration. If a field cannot be parsed from the slicer it will be omitted.” Thumbnails work the same way. Moonraker reads the base64 preview blocks your slicer embedded and writes them out as PNG files next to the G-code. It never renders the geometry itself, so a file exported with previews switched off has no thumbnail anywhere in the stack, in any front-end.

Print history is a separate component with the same shape of limit. Each entry gets an incrementing job id and stores the G-code filename, status, durations, filament used, and a snapshot of that metadata. No field points at a source model, because there is no source model in the system. Each file also carries a uuid, but it is generated randomly when the metadata is extracted, not derived from the content, so two copies of an identical slice under different names are unrelated as far as Moonraker is concerned. History entries also carry an exists flag that goes false once the file is modified, which is honest of it but not the same as keeping the record.

One more thing that matters if you have more than one machine: a Moonraker instance serves one printer. Whatever you are browsing, you are browsing that printer.

Which wall you hit

Five questions, and they sort the problem quickly:

1. Can you see what is on all your machines in one list?
2. Given four files named some variant of bracket, can you tell which one printed cleanly?
3. Can you get from a G-code file to the STL or 3MF it was sliced from?
4. Do you get a preview for a file whose slicer did not embed one?
5. Does the record survive deleting the file to free up the SD card?

Moonraker answers no to all five, and both front-ends inherit those answers because they read the same API. Nobody can fix questions one and four in the interface layer. The other three ask for data that was never captured in the first place.

If you read that list and did not care about any of it, you do not need a different tool. One printer, a folder per project, and a few dozen files a year is a situation Fluidd’s file manager handles completely, and bolting a library onto it is administration you will resent. Come back when one of the five starts to sting.

If the interface is the wall

Most of the job is common ground, so start there. Fluidd 1.37.4 and Mainsail 2.18.2, both checked on August 17, 2026, give you a sortable table with a drag-reorderable column picker, multi-select with bulk delete, ZIP download of a selection, folder creation, rename, duplicate, drag-to-move onto a folder, drag-and-drop upload from the desktop, and per-file print, preheat, metadata rescan, edit, download, and a built-in 3D G-code viewer. Both toggle hidden files and already-printed files. Both show the slicer’s embedded thumbnails inline. Neither has a grid or gallery view, in case that is what you were hoping for.

The differences are real but narrower than the arguments about them suggest. Fluidd’s file manager has a fuzzy “go to file” search that covers the whole root instead of filtering the current directory, which is the single feature I would miss most after living with it. A time-analysis action hands the file to Moonraker’s [analysis] component, which runs klipper_estimator over it and rewrites the time estimates in place. It previews images, video, and rendered Markdown, not only G-code. It carries more metadata columns, including filament and extruder colors, per-filament weights, printer vendor and model, and slicer version. Its filters know about Klipper and Moonraker and Crowsnest backup files specifically. It warns you when the disk drops below the lower of 1 GB or 20 percent, and it will accept a whole folder dragged in from the operating system.

Mainsail’s file browser is not documented on its docs site, so what follows comes from reading its source. It puts print history on the file row more usefully than Fluidd does, with columns for last start and last end time, last print duration, last total duration, and last filament used. Fluidd surfaces overlapping history columns but not the last end time. Mainsail also offers a batch add-to-queue directly from a file row, with a count, which is the fastest route I know to queueing eight copies of one part. Where Fluidd lists move among its file operations and lets you enable drag and drop in settings, Mainsail has no move command in its menus at all, so dragging a row onto a folder is the only way to reorganize.

The job queue deserves a mention here, because people go looking for a better file browser when what they actually wanted was a queue. It is an opt-in Moonraker component, [job_queue], and both front-ends expose it. Fluidd documents a queue card with reordering, a multiply action, and footer totals for filament and combined print time. Mainsail’s queue panel supports reordering too. It holds filenames on that one printer, so it is a print spooler and has nothing to do with organizing a collection.

Neither front-end gives you a combined file view across printers, and this is where the phrase “multiple printers” misleads people. Fluidd switches between printers in one browser tab, but it fully reinitializes against the newly selected Moonraker instance, so you are looking at one machine at a time. Mainsail adds multiple printers and has a farm overview page on top of that, which shows state, current filename, progress, and an optional webcam per machine. It contains no file browser. Browsing files is always scoped to the instance you have selected.

If the data is the wall

A library sits behind the file browser instead of replacing it, and it holds the four things Moonraker has no field for: the source mesh, the link from a slice back to that mesh, a verdict on each slice, and a record that outlives the file.

The unit of storage becomes the model, not the file on a machine. In PrintStash 0.11.4, a model holds its source mesh alongside the G-code sliced from it, each slice stored as a numbered revision with an optional label, free-text notes, and one outcome from known_good, needs_test, failed, or archived. Exactly one G-code revision per model can be marked recommended, and a partial unique index in the database enforces that, so the interface cannot get it wrong. That is the answer to question two on the list above, and tracking known-good revisions covers how the outcome gets set.

Slicer settings are parsed out of the file and kept on the revision, covering material, layer height, nozzle diameter, temperatures, filament weight, and estimated time from OrcaSlicer, PrusaSlicer, Bambu Studio, and Cura output. So far this overlaps with what Moonraker already parses. The difference is where it lives. It stays attached to a revision of a model, it survives the file being deleted from the printer, and you can put two slices of the same part side by side.

Previews are one thing a library can do that Moonraker cannot. PrintStash rasterizes the source mesh itself, in numpy and Pillow with no GPU involved, so a part whose G-code carries no thumbnail still has a picture, taken from the STL. For 3MF it falls back to the archive’s embedded preview when rendering fails or the file is too large for the configured cap. STEP and STP need OpenCASCADE tessellation, which the full image now does on both amd64 and ARM; the lite image stores them without a generated preview.

For printer-side files, PrintStash reads the machine’s inventory and matches each remote filename back to a revision it already has, marking the rest external. It does not copy the files back, and the matching has failure modes you should understand before relying on it, both covered in syncing a printer’s files with a library. Inventory is not universal across providers either. Moonraker is the stable provider and supports it, PrusaLink and OctoPrint support it in beta, and Bambu LAN and Elegoo Centauri expose no file inventory at all, so on those machines there is nothing to read. The compatibility matrix is the current per-provider list.

What stays in Fluidd or Mainsail

Everything to do with running the machine. Webcam, console, macros, temperature graphs, homing and jogging, configuration editing, firmware restarts, and hands-on intervention during a print all stay exactly where they are, and a library has no business trying to take them. PrintStash connects to the same Moonraker instance Fluidd or Mainsail is already using, so a file it uploads appears in their file list like any other, and connecting a Klipper printer is a URL and an optional API key. The controller overview has more on where the boundary sits.

One caveat changes how you work, not what you install. When a print starts from Fluidd or Mainsail instead of from the library, PrintStash notices it through Moonraker’s status feed and records the job, but it matches jobs by printer and remote filename and has no live job to attach that print to. The result lands on an internal placeholder record instead of on the model, so the durations and filament are captured while the outcome never reaches the revision you were testing. If you want the print history to accumulate against your models, send the job from the library and use the front-end to watch it. Reprints pressed in Fluidd are the most common way a revision’s history quietly stops being complete.

Questions that come up

Is Fluidd or Mainsail better for managing files?

They are close enough that file management alone is a weak reason to switch, and both cover the same core operations. Fluidd is stronger on finding things and on inspecting them: it has a fuzzy search across the entire root instead of a filter on the current folder, more metadata columns, previews for images and video and Markdown, backup-file-aware filters, a low-disk warning, and integration with Moonraker’s [analysis] component for rewriting time estimates. Mainsail is stronger on the printing side of the file row, with columns for last start and end time and last filament used drawn from print history, plus a batch add-to-queue action straight from a file. Install whichever you prefer for everything else, then treat the file manager as a small tiebreaker, not the deciding factor.

Does every G-code file get a thumbnail?

No, and this is not something a front-end can fix. Moonraker extracts thumbnails from base64 preview blocks that your slicer embedded in the G-code, and it never renders the model geometry itself. The only rendering it does is downscaling an existing embedded preview to 32 by 32 when that size is missing. If you exported without thumbnails enabled in OrcaSlicer, PrusaSlicer, Bambu Studio, or Cura, no Moonraker client will show you a picture of that file. Turning previews on in the slicer fixes it for future exports but does nothing for files already on the machine, which have to be resliced.

Can I browse all my printers’ files in one list?

Not in Moonraker, Fluidd, or Mainsail. A Moonraker instance serves a single printer, so there is no cross-instance file API to build such a view on. Fluidd switches between printers in one browser tab but fully reinitializes against the selected instance, and Mainsail’s farm overview page shows per-machine state, current filename, progress, and webcam without any file browser in it. Both are one machine at a time by design. A combined view has to come from something that indexes each printer separately and correlates the results, which is what a library’s inventory sync does.

Does Moonraker’s print history tell me which slice worked?

Only in the weakest sense. History entries record status, durations, and filament used against a G-code filename, so if you never rename or reslice anything you can read a file’s outcome from them. The moment you export a second variant under a new name, nothing connects the two, because there is no model that both files belong to and the per-file uuid is random, not a content hash. Entries also carry an exists flag that turns false once the file is modified. So the history knows a job happened and roughly how it went, without knowing which version of which part it was.

If I press print in Fluidd, does the result reach my library?

Partly, and the gap matters. PrintStash watches Moonraker’s status feed, so a job started outside the library is still captured with its duration and measured filament. Because it matches jobs by printer and remote filename and finds no live job waiting, the record lands on an internal placeholder rather than on the model the file came from. The revision you were testing does not get its outcome updated. Sending from the library and then watching the print in Fluidd or Mainsail gets you both the interface you like and a history that stays attached to the part.

Do I have to replace Fluidd to add a library?

No, and you should not. A library talks to the same Moonraker instance over the same API, so Fluidd or Mainsail keeps working unchanged and files pushed from the library appear in their file list like anything else. What it costs you is another service and another database to back up, which is a real price for a single-printer setup with a tidy directory tree. The trade only makes sense once you have enough parts, enough slices of the same part, or enough machines that filenames have stopped being a usable index.

Sources

• Moonraker file manager API, history API, job queue API, and configuration reference for roots, valid G-code extensions, metadata fields, thumbnail extraction, and history keying. Checked August 17, 2026.
• Fluidd file manager, job queue, and multiple printers documentation, against Fluidd 1.37.4. Checked August 17, 2026. Note that the Fluidd docs site builds from the project’s development branch, so it can describe behavior slightly ahead of the tagged release.
• Mainsail thumbnails and printer settings documentation, against Mainsail 2.18.2. Checked August 17, 2026. Mainsail’s G-code file manager has no documentation page, so the file-row and column details above were read from the project source.
• PrintStash compatibility matrix and the printers guide for per-provider inventory support in the shipped release.