Star 168 Get Started
← Blog

3D printer ecosystems for self-hosted software

Klipper machines run any software, Bambu needs LAN mode plus Developer Mode, Prusa sits in between, and Elegoo is split. What each interface lets software do.

comparisonprintersself-hostedklipper

If running your own software matters, buy a printer that speaks Moonraker. That is the whole answer, and everything below is the reasoning and the exceptions.

The thing that decides your options is not the brand on the box, it is the control interface the printer exposes to your network. A Voron, a Creality machine running Klipper, and an Elegoo Neptune 4 are the same printer as far as your software is concerned, because all three answer to the same open API. A Bambu P1S and an Elegoo Centauri Carbon are each their own protocol, spoken by a much shorter list of tools.

Most buying guides never mention this, because they compare print quality and speed on machines people mostly drive from the vendor’s own slicer. It surfaces later, when you want a shared library, a queue across several machines, or a record of what printed well.

Klipper and Moonraker: the open end

Klipper splits the job in two. The printer runs the motion firmware, and a Linux host runs Moonraker, an HTTP and WebSocket API server that anything on your network can talk to. Because that API is public and stable, the tooling around it is the deepest in the hobby: Mainsail and Fluidd for per-printer control, and libraries and farm tools that connect over the same endpoints.

The practical effect is that a Klipper machine gives third-party software the full set. Live status, file upload, starting a print, pause and resume and cancel, listing and deleting files already on the printer, raw G-code, and print history with measured filament consumption. In PrintStash that is the one provider marked stable rather than beta, and it is the only one where per-print cost is based on grams the printer actually reported rather than the slicer’s estimate.

Who ships it: Voron and Ratrig builds, most Creality and Sovol machines now, the Elegoo Neptune 4 family, and anything you convert yourself. The last part matters. Klipper is something you can add to a printer that did not come with it, which is not true of any proprietary interface.

Marlin plus OctoPrint: old, wide, and per printer

The classic arrangement is a Marlin printer connected by USB to a Raspberry Pi running OctoPrint, which is a control server with an HTTP API and, more importantly, a plugin repository holding 404 plugins as of August 19, 2026, 331 of them Python 3 compatible.

OctoPrint’s shape is one instance per printer. That is fine for one machine and gets tedious for six, which is why farm software tends to sit above it rather than inside it. Third-party access is straightforward: an API key gets you status, upload, start, file listing, and controls. What you do not get is measured filament consumption, so cost stays an estimate.

If a printer has a USB port and runs Marlin, this path is available regardless of who made it, which makes OctoPrint the fallback for hardware nobody else supports.

Bambu: local access, on Bambu’s terms

Bambu machines are the strongest out-of-box experience and the most conditional to automate.

LAN Only mode gives you a local channel: an access code, MQTT for status and commands, and FTPS for file transfer. On firmware carrying Bambu’s authorization control system, that channel is capability-restricted unless you also enable Developer Mode from the same screen. Without it, recent firmware still publishes status to anything that asks, while starting a job, moving an axis, and heating the machine are refused unless the request came from Bambu’s own software. Developer Mode exempts the printer from those checks and also stops it being bound to Bambu Cloud. X1 machines need a microSD card inserted before a LAN print will start.

None of that is unusable, and plenty of people run Bambu printers entirely locally. But you are operating inside a policy that Bambu has changed before and can change again, on firmware you are periodically asked to update. Sending prints to a Bambu printer without Bambu Cloud covers the setup and the caveats in detail.

Prusa: a documented local API, minus the extras

Prusa’s newer machines expose PrusaLink on the local network, with HTTP Digest authentication on current firmware and a legacy API key on older setups. It is a real local API: polled status and temperatures, upload, explicit start, remote file listing and deletion, and print controls, with no requirement to route anything through Prusa Connect.

What it does not offer is raw G-code or measured filament consumption, so cost falls back to the slicer’s estimate and a tool cannot script arbitrary machine commands. Prusa also publishes its firmware and slicer as open source, which is a different kind of openness from an open control API, and worth separating when you are comparing.

Elegoo: two ecosystems in one brand

Elegoo is the clearest illustration that the brand is not the unit. The Neptune 4 family runs Klipper, so it lands in the open column with everything that implies. The Centauri Carbon runs Elegoo’s own firmware and speaks SDCP over a WebSocket, while the Carbon 2 uses authenticated local MQTT.

Support for those two is real and beta: live status, controls, and, since PrintStash v0.11.3, upload. File inventory stays disabled because probing for it can crash the original Carbon’s printer daemon. Two machines from the same manufacturer, and one of them gives your software twice as much to work with. Self-hosted print management for Elegoo printers covers the split in practice.

The short version

Ecosystem Local API Third-party control File inventory Measured filament
Klipper via Moonraker Open HTTP and WebSocket Full, including raw G-code Yes Yes
Marlin via OctoPrint Documented, API key Status, upload, start, controls Yes No
Bambu LAN MQTT and FTPS, access code Restricted unless Developer Mode is on No No
PrusaLink Documented, Digest auth Status, upload, start, controls Yes No
Elegoo Centauri SDCP or local MQTT Status, upload, start, controls, beta No No

What I would actually tell someone buying

If self-hosted software is a requirement, buy Klipper, or buy something you can convert to Klipper. The gap is not marginal: file inventory, real consumption data, and raw commands all come from that column, and it is the only interface with more than one mature third-party client.

If you want the best printer out of the box and self-hosting is a nice-to-have, buy the Bambu and turn on LAN Only plus Developer Mode on day one. You will get a working local setup and you should know it depends on a vendor policy rather than a published standard.

If you are somewhere in between, a Prusa on PrusaLink is the least dramatic middle: a documented local API, no cloud requirement, and a company with a long record of not breaking that.

For what it is worth, PrintStash supports all five, so this recommendation costs it nothing to make. The reason to be honest about it is that the alternative, telling people every ecosystem is equally open, is the thing they discover to be untrue about a week after the printer arrives. If you already own hardware from one of these ecosystems, the printer you buy does not have to decide your library is the other half of the argument.

Questions that come up

Does buying a Bambu mean I cannot self-host at all?

No. LAN Only mode is a real local channel, and a self-hosted library can upload G-code, start a print, and pause or cancel it without touching Bambu Cloud. The condition is Developer Mode on firmware that carries the authorization control system, and the cost of Developer Mode is that the printer can no longer be bound to the cloud. The honest difference from Klipper is not capability today, it is who decides. An open API stays available because it is published; a vendor’s local mode stays available because the vendor keeps allowing it.

Can I add Klipper to a printer that did not come with it?

Usually, and it is the most reliable way to move a machine into the open column. Klipper runs the motion planning on a Linux host and flashes its own firmware to the printer’s mainboard, so what matters is whether your board is supported and whether you are comfortable flashing it. Most common Marlin boards are. What you get in return is the Moonraker API and everything that speaks to it. The conversion is not free: you rebuild your printer profiles and macros, and vendor features that depended on stock firmware may not survive.

Is OctoPrint still worth using in 2026?

For a single Marlin printer or a machine nothing else supports, yes. Its plugin repository is the largest in the hobby, and its API is well documented and stable. The two things to plan around are that it runs one instance per printer, which does not scale gracefully to a farm, and that it cannot report measured filament consumption, so per-print cost stays an estimate. Many people run OctoPrint for control and a separate library for files, which is the arrangement running PrintStash alongside OctoPrint describes.

If I already own a mixed fleet, does this matter?

It matters for what you can expect from each machine rather than for whether the fleet works. A library that speaks several providers will drive all of them, and the capability differences show up per printer: the Klipper machines report real filament use and expose their file lists, and the others do not. The practical advice for a mixed fleet is to keep the capability differences visible rather than assuming parity, which the compatibility matrix breaks down per provider.

Sources