Bambuddy: a self-hosted Bambu Lab dashboard, and the H2/P2S archive catch
Your Bambu Lab. No Cloud. Your Rules. Self-hosted command center for Bambu Lab — from one A1 to an entire print farm.
At a glance
- What is it?
- Bambuddy is an AGPL-3.0 Python project that replaces Bambu Lab's cloud with a local command center for one A1 or a whole print farm. The README's own warning about H2-series and P2S archiving is the most useful part of the documentation.
- Who is it for?
- Adopt Bambuddy if you run Bambu Lab hardware and want print history, filament tracking and job control on a machine you own, and if you are willing to start prints from Bambuddy or slice in OrcaSlicer so that files land on the card. Do not adopt it if your workflow is Bambu Studio's Print button on an H2-series or P2S printer, because the README states those prints archive with a name and timing but no thumbnail, filament total or cost.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Bambuddy targets: print history that lives on someone else's server
Bambu Lab printers work fine out of the box, but the management layer around them runs through Bambu's cloud. The README frames the project as a replacement for that layer rather than for the slicer: a self-hosted command center for Bambu Lab hardware, scaled from a single A1 to an entire print farm. The audience is the person who already owns the printer and now wants the job queue, the archive and the filament ledger on a machine they control.
That framing matters because it sets the boundary of the project. Bambuddy is not a slicer and not firmware. It sits beside Bambu Studio and OrcaSlicer, and the README treats those tools as part of its own workflow rather than as competitors. The topics list on the repository includes 3mf-files, gcode and filament, which points at the data the dashboard is built to track: what was printed, with which material, and at what cost. Anyone who only wants to slice and hit print will not find much here. Anyone who has tried to reconstruct last month's filament spend from a cloud dashboard will recognise the gap.
How the pieces fit: printer, card, dashboard
The mechanism visible in the README is a file path rather than a protocol description. Bambuddy can start a print, and when it does, the sliced file is placed on the printer's external storage in one step. The README states that starting the print from Bambuddy, or slicing in OrcaSlicer, both put the file on the card in one step. From that card the dashboard can read back what it needs to build an archive entry: thumbnail, filament total and cost.
The alternative path is Bambu Studio's Print button, which sends sliced files to the printer's internal memory. The README says Bambuddy cannot read that memory. The consequence is stated plainly: those prints archive with a name and timing but no thumbnail, filament total or cost. The README also notes that the printer's Store sent files on external storage option does not change this, and that the behaviour was measured on an H2C and an H2D with that option enabled. Upstream tracking is at BambuStudio#10481. X1 and P1 series owners are told they are unaffected.
So the data flow has a fork in it, and the fork is decided by which button you press, not by a setting inside Bambuddy. The README suggests the workaround for people who stay in Bambu Studio: use Send with External picked, then start the print afterwards, because Print itself offers no choice. Every one of those routes needs a card or stick in the printer. That is a concrete constraint, not a configuration preference.
Getting it running: what the README actually gives you
The README's Quick Start section is linked from the top navigation, but the extracted text stops before it delivers install commands. What the material does provide is a live demo at demo.bambuddy.cool, described as a private instance you can spin up in roughly ten seconds with no install and no signup, in a thirty-minute session. There is also a wiki at wiki.bambuddy.cool and a troubleshooting page at wiki.bambuddy.cool/reference/troubleshooting, which the README links to for the archive-card behaviour.
I have not installed or run this project, so I will not invent a docker run line or a config key that is not in the material. The honest position is that the install path lives in the Quick Start section of the README and in the wiki, and that the demo is the lowest-commitment way to see the interface before you commit a host to it. What can be confirmed from the repository metadata is the language (Python) and the licence (AGPL-3.0). Anything beyond that, including port numbers, environment variables and volume mounts, would be guesswork on my part.
The release history is worth reading before you pick a tag. The most recent entries in the supplied material are v1.2.6b1-daily.20260907, a daily beta build from 2026-09-07, and two stable releases before it: v1.2.5.5, labelled a hotfix, on 2026-08-30, and v1.2.5.4 on 2026-08-29. A hotfix landing one day after a release, with daily beta builds running alongside, tells you the project is moving quickly. If you want stability over novelty, the hotfix tag is the more defensible starting point than the daily build.
The H2-series and P2S archive gap is the real limitation
The README puts its most important paragraph behind an IMPORTANT callout, and it deserves that placement. On H2-series and P2S printers, the choice of how you send a print determines what Bambuddy can archive. Start from Bambuddy or slice in OrcaSlicer and you get the full record. Use Bambu Studio's Print button and you get a name and timing, with the thumbnail, filament total and cost missing.
This is a genuine failure mode, and it is not one the user can configure away. The README is explicit that the printer's Store sent files on external storage option does not help, based on measurements on an H2C and an H2D. The root cause sits upstream in Bambu Studio's default, tracked as BambuStudio#10481, which means Bambuddy cannot fix it from its side even if it wanted to. The project's response is documentation plus a workaround, not a patch.
For a farm operator, the practical effect is a split archive. Prints launched through Bambuddy carry cost and material data. Prints launched from Bambu Studio on an affected model do not, and the gap is invisible until you try to total filament usage for a month. If your operators habitually slice and press Print in Bambu Studio, Bambuddy's tracking will be quietly incomplete on those machines. That is the case where this is the wrong tool, or at least the wrong tool for the workflow you already have.
Bambuddy against Bambu's cloud, and against Bambu Studio
The comparison the README invites is with Bambu Lab's own cloud. Two publications quoted in the README reach the same conclusion independently: Fabbaloo writes that the features seem to exceed those provided by Bambu Lab's own cloud, and 3Druck.com writes that the list of functions goes beyond what Bambu Lab offers in its own cloud. The difference in approach is not feature count, it is custody. Bambu's cloud is a service the vendor operates and you reach over the network. Bambuddy is software you run, and the README's own slogan is Your printers. No cloud. Your rules.
Against Bambu Studio the difference is sharper. Bambu Studio is the slicer and the send path, and on H2-series and P2S hardware its Print button writes to internal memory that Bambuddy cannot read. OrcaSlicer, by contrast, is named in the README as one of the two ways to get a file onto the card in one step. So the practical choice is not Bambuddy or Bambu Studio. It is which slicer and which send button you use, with Bambuddy reading the result. A user who switches to OrcaSlicer and starts prints from Bambuddy gets the full archive. A user who stays in Bambu Studio and presses Print gets a partial one.
One more comparison is worth naming even though the README does not: running nothing at all. Bambu's cloud requires no host, no updates and no card in the printer. Bambuddy trades that for control, and the trade is only worth making if you actually want the archive.
Licence, maintenance and the cost of running your own
Bambuddy is AGPL-3.0. That is a copyleft licence with a network clause, which means the obligations extend to users who interact with a modified version over a network, not just to people who receive a binary. If you fork Bambuddy, modify it and expose it to others, the licence's terms apply to that deployment. I am not giving legal advice, and the precise scope of your obligations depends on what you do with the code. If you plan to modify and redistribute, read the LICENSE file and, where it matters, talk to someone qualified. If you only run it for yourself, the practical effect is close to nil.
Maintenance cost is visible in the release cadence. Stable releases v1.2.5.4 and v1.2.5.5 landed a day apart, and the latter is labelled a hotfix, which means a defect shipped in the first and was corrected in the second. Daily beta builds such as v1.2.6b1-daily.20260907 run in parallel. A self-hosted tool with this tempo needs an update habit, and an update habit needs a rollback plan. The README does not describe a migration or backup procedure in the material I have, so treat that as something to confirm in the wiki before you put a farm's history into it.
There is also the card requirement. Every route the README describes for getting a sliced file onto external storage needs a card or stick in the printer. That is a small hardware cost and a small operational one, but it is a dependency, and it is the kind of dependency that bites when someone pulls the stick to copy files.
Who should run Bambuddy, and what to check first
Bambuddy fits the operator who owns Bambu Lab hardware, wants print history and filament accounting on local storage, and is willing to change one habit: start prints from Bambuddy, or slice in OrcaSlicer. If you are on X1 or P1 series, the README says the archive caveat does not apply to you, which makes the decision simpler. If you run a farm and your operators already work through a dashboard rather than a desktop slicer, the fit is natural.
It does not fit the person who wants to keep pressing Print in Bambu Studio on an H2-series or P2S machine and still expects a complete archive. It also does not fit anyone who wants a zero-maintenance service. The release cadence and the hotfix pattern mean you will be applying updates, and the AGPL-3.0 terms mean you should read the licence before you build anything on top of the code.
What to verify before you commit: open the Quick Start section of the README and the wiki at wiki.bambuddy.cool for the actual install steps, since the material here does not include them. Check the troubleshooting page at wiki.bambuddy.cool/reference/troubleshooting for the archive-card behaviour on your model. Try demo.bambuddy.cool first, since it costs thirty minutes and no install. Then pick a tag: v1.2.5.5 is the most recent stable release in the supplied material, and the daily beta builds are not the place to start a farm.
Editorial conclusion
Adopt Bambuddy if you run Bambu Lab hardware and want print history, filament tracking and job control on a machine you own, and if you are willing to start prints from Bambuddy or slice in OrcaSlicer so that files land on the card. Do not adopt it if your workflow is Bambu Studio's Print button on an H2-series or P2S printer, because the README states those prints archive with a name and timing but no thumbnail, filament total or cost. Before committing, verify the current release tag against the wiki at wiki.bambuddy.cool, confirm the archive behaviour on your specific model, and read the AGPL-3.0 terms if you intend to modify and redistribute the code.
Community notes