Does your printer limit self-hosted tools?

Most buying advice treats a 3D printer like a software subscription: Klipper people run Mainsail or Fluidd, Bambu people run Bambu Studio, Prusa people run Prusa Connect. The first half of that is true. The printer you buy does decide the software you drive it with.

What does not follow is the conclusion most guides leave you with: that your files, version history, and print record have to live inside whichever stack you picked. A self-hosted library is a separate layer, and it can sit across every printer you own regardless of who made them. PrintStash connects to Moonraker/Klipper (stable), OctoPrint, PrusaLink, Bambu LAN, and Elegoo Centauri printers (all four in beta), so one library covers a Voron, an old Marlin machine on OctoPrint, a Prusa, a Bambu, and a Centauri Carbon at once.

So the short answer is no. The printer you buy decides how you control that machine. It does not decide where your library lives. This page walks through what each printer interface actually exposes, what stays constant across all of them, and what is still beta.

This is the vendor-neutral half of the argument. Its sibling, which printer ecosystem has the best self-hosted software support, covers the buying-first view. This one covers what stays true after the box is open.

Two decisions bundled into one purchase

The first choice is the control stack: the firmware and dashboard you use to drive that machine. Mainsail or Fluidd on Klipper, OctoPrint over USB on older Marlin hardware, Bambu’s own tools, Prusa’s. This choice is largely locked in by the printer, and that is fine. It is a decision about how you want to run the machine.

The second choice is the library layer: where models, G-code revisions, print history, and known-good verdicts live. Most ecosystem comparisons only discuss the first, because vendors sell complete stacks. The second is where mixed fleets, printer upgrades, and years of print history actually live, and it is the layer a vendor has no incentive to keep portable.

What each printer actually exposes

PrintStash’s compatibility matrix keeps the current per-provider detail. The short version, verified against the shipped release, v0.12.1:

Printer interface	Support level	What it exposes to third-party software
Moonraker (Klipper)	stable	Live status over WebSocket, upload, start, pause/resume/cancel, remote file inventory, raw G-code, measured filament consumption
OctoPrint	beta	Polled status, upload, start, pause/resume/cancel, remote file inventory and deletion
PrusaLink	beta	Digest or API-key auth, polled status, upload and start, remote file inventory and deletion, controls
Bambu LAN	beta	MQTT status and FTPS transfer with an access code; upload never auto-starts, an explicit start is its own action; control requires Developer Mode on current firmware, which opts the printer out of Bambu Cloud binding
Elegoo Centauri	beta	Live status and controls over SDCP (original Carbon) or authenticated local MQTT (Carbon 2); upload since v0.11.3

Every one of these exposes enough for a library to track files and jobs. Only Klipper reports measured filament consumption, so per-print cost stays an estimate on the other four. Measured elapsed duration reaches a little further: OctoPrint, PrusaLink, and Elegoo Centauri report it, while Bambu LAN reports neither measurement. These are printer-side limits. No library can fix them by trying harder.

Two caveats sit inside the table. Raw G-code commands are Moonraker-only; none of the other interfaces accept arbitrary machine input. And the Elegoo upload path is newer evidence than the rest: it works, with a real-world confirmation on the original Carbon so far, while the Carbon 2 path has not yet been exercised on physical hardware.

What stays constant across all five

Because the library layer sits above the printer, these work the same no matter which machine produced the file:

• One searchable home for STL, 3MF, OBJ, STEP, and G-code files, with content-hash duplicate detection.
• G-code revisions with known-good status, so a failed print points back to the revision that produced it and to the earlier one that worked.
• Print history that accumulates across printers instead of dying with a brand-specific tool.
• A mixed fleet under one roof: a Bambu and a Klipper Voron sit in the same library, with per-printer capability differences visible rather than smoothed over.

The honest limits

Four of the five providers are beta, and the word carries weight. Beta means the protocol logic is tested against mocked transports and emulators, with real-firmware coverage growing and documented per provider. Concretely: Bambu LAN control depends on Developer Mode, a vendor policy that has changed before and can change again. Elegoo file inventory stays off by design: asking the original Carbon for its file list can take down the printer daemon that everything else depends on, so PrintStash never sends that probe. PrusaLink and OctoPrint do not report measured filament, so cost stays an estimate there.

Vendor neutrality does not mean every printer behaves identically. It means your files and history do not move when you change printers.

The buying advice, flipped

The ecosystem guide ends with buying advice: if self-hosted software is a requirement, buy a printer that speaks Moonraker. That still stands, because control depth lives in the open column. The flipped half is for everyone who already owns, or has fallen for, a printer from the other column: the library layer does not punish you for it.

Buy the printer you want. Keep the library vendor-neutral, and the printer choice stays what it should be, a hardware decision. When you replace that printer in three years, the revisions, verdicts, and history move with you instead of staying behind with the machine.

Questions that come up

I already own a Bambu. Do I need Klipper to get a proper library?

No. LAN Only mode plus Developer Mode opens a local channel a self-hosted library can use for status, upload, and job control, with the tradeoff that Developer Mode blocks binding the printer to Bambu Cloud. The difference from Klipper is not capability today, it is who guarantees the interface: a published open API versus a vendor policy. PrintStash records externally started Bambu jobs either way, including metadata-only entries when the exact G-code is no longer retrievable from the printer’s cache.

Does a cross-vendor library work worse than the vendor’s own tools?

On control, sometimes, yes: the vendor’s tool always supports its own features first. On the library layer, most vendor tools have nothing to compare. File history across brands, known-good verdicts, and duplicate detection are not jobs Bambu Studio, PrusaSlicer, or Bambu Handy attempt. They solve different problems, and running both side by side is the normal arrangement; running PrintStash alongside OctoPrint, Fluidd, and Mainsail describes it for the Klipper case.

What happens to my print history when I switch printer brands?

Nothing, as long as the history lives in the library rather than on the printer or in a brand tool. That is the practical payoff of keeping the layer vendor-neutral: the record of what printed well survives the hardware. One caveat comes straight from the table above: measured filament numbers exist only for prints that ran through Moonraker, so a history built across brands mixes measured and estimated costs.

Self-hosted print management for Elegoo printers and sending prints to a Bambu without Bambu Cloud cover the two beta integrations in depth.

Sources

• PrintStash provider support notes (provider-support.md) and known-limitations.md at tag v0.12.1 for support levels, per-provider capabilities, and the Elegoo validation status. Checked August 22, 2026.
• Bambu Lab’s third-party integration page for the authorization checks on normal LAN mode, the Developer Mode exemption, and its cloud-binding tradeoff. Checked August 22, 2026. These rules have been tightened and loosened before, so re-check that page before building anything on it.
• The compatibility matrix for per-provider capabilities in the shipped release.