Bambuddy: Self-Hosted Bambu Lab Management Without the Cloud

What Bambuddy is and what problem it solves

Bambu Lab printers communicate with Bambu's cloud service by default. Remote monitoring, print scheduling and file management all route through Bambu's servers. This creates a dependency: if Bambu's cloud is unavailable, or if the owner is uncomfortable with their print data leaving their network, the printer's remote features stop working.

Bambuddy is a self-hosted Python application that speaks the same protocols as Bambu's cloud but runs on your own server or NAS. Once installed and configured, your slicer connects to Bambuddy's virtual printer instead of Bambu's servers. Bambuddy then proxies the connection to the physical printer on your local network, handling authentication, file transfer, camera streaming and MQTT messaging.

The README describes two press descriptions of the project: XDA-Developers called it the companion app that Bambu Lab should have built from day one, and Fabbaloo noted that its feature set already exceeds Bambu's own cloud. Bambuddy archives every print file (the 3MF files that slicers generate), logs timing and filament usage, and shows live printer status including temperatures, layer progress and the printer camera.

The project is aimed at Bambu Lab printer owners who have one to several printers and want local-first control. It is particularly useful for anyone running multiple printers as a small print farm.

Core features: archive, monitor, remote print and slicer integration

Bambuddy's archive records each print as a 3MF file with associated metadata: print name, timing, filament totals, cost (if configured) and a thumbnail. The README describes this archiving as the central capability the project was built around. The primary limitation here applies to H2-series and P2S owners: when a print is started from Bambu Studio's Print button, the file goes to the printer's internal memory rather than the card, and Bambuddy cannot read it. Those prints archive with a name and timing but without thumbnail or filament data.

The monitoring dashboard shows live CPU, RAM, disk and network data for the server alongside per-printer status. Each printer card shows current status with indicators for VMs and LXC containers. Wait, that's ProxMenux. For Bambuddy, each printer card shows the printer's current state, temperature readings, filament loaded and a live camera feed.

Proxy Mode is the remote printing feature. It acts as a relay between the slicer and the physical printer, with end-to-end TLS encryption using the printer's own certificate. The README notes that Tailscale integration is available per virtual printer: toggle it on, mount the host's Tailscale socket, and the virtual printer card shows the Tailscale IP, which can be pasted into the slicer to reach the printer from anywhere on your tailnet.

The integrated slicer lets you drop an STL or 3MF file into Bambuddy's File Manager, click Slice, and receive a ready-to-print .gcode.3mf back in the same folder. The slicing runs server-side in a sidecar container. You can import a Printer Preset Bundle (.bbscfg) exported from Bambu Studio to bring your own printer profiles into the dialog.

Installing Bambuddy with Docker

The recommended installation path is Docker Compose. The compose file is included in the repository:

docker compose up -d

This pulls the pre-built image from ghcr.io/maziggy/bambuddy:latest. To build locally from source, add --build:

docker compose up -d --build

On Linux, the compose file uses host network mode, which is required for printer discovery and camera streaming. On macOS and Windows, Docker Desktop does not support host mode. The README instructs those users to comment out network_mode: host and uncomment the ports section instead, noting that printer discovery will not work automatically and printers must be added manually by IP.

The compose file requires NET_BIND_SERVICE capability to allow binding to privileged ports (322 for RTSP camera proxy and 990 for FTPS) as a non-root user.

Environment variables for user and group IDs, PUID and PGID, default to 1000:1000. The entrypoint script normalizes file ownership inside the data and logs volumes at startup and drops to those privileges before running the application.

For users who want to try daily beta builds, the README describes the daily beta tagging pattern v1.2.6b1-daily.YYYYMMDD and notes that the docker-publish-daily-beta.sh script handles that release cycle.

The H2-series archive limitation and how to work around it

Bambuddy's README dedicates a prominent warning to H2-series and P2S owners. When a print is started from Bambu Studio using the Print button, the slicer sends the sliced file to the printer's internal memory directly. Bambuddy sits outside this path and cannot intercept or read that file. The archive entry for such a print contains only the print name and timing, without a thumbnail or filament total.

The README notes that enabling the printer's Store sent files on external storage option does not change this behavior, citing testing on both H2C and H2D models with that option enabled. The issue is tracked in BambuStudio issue 10481.

Three workarounds are documented:

1. Start the print from Bambuddy's interface directly. 2. Slice in OrcaSlicer, which puts the file on the SD card or USB stick in one step. 3. Use Bambu Studio's Send button with External selected, then start the print afterwards.

All three paths require a card or stick in the printer. X1 and P1 series printers are unaffected by this limitation.

This is a significant consideration for anyone buying an H2-series printer expecting full Bambuddy archive support. The limitation is a consequence of how H2-series firmware handles file routing, not something Bambuddy can work around on its own.

SpoolBuddy: integrated filament management

The spoolbuddy/ directory in the repository indicates that Bambuddy includes integrated filament spool management. SpoolBuddy is a companion feature that tracks filament inventory alongside print archives. The directory exists at the same level as the main backend and frontend, suggesting it is a first-class feature rather than an external dependency.

Integrating spool management with the print archive means that filament consumed per print can be tracked against a spool's remaining capacity. This is relevant for print farm operators who need to know when a spool needs replacing before a long print job starts.

The README does not describe SpoolBuddy's interface in detail beyond its presence. Users interested in the spool management workflow can consult the wiki at wiki.bambuddy.cool.

How Bambuddy compares to Bambu Studio for local management

Bambu Studio is Bambu Lab's official desktop slicer and printer management application. It connects to printers via the Bambu cloud by default and provides a rich UI for slicing, file management and print monitoring. Bambu Studio runs as a desktop application rather than a server.

Bambuddy's key difference is its server model: it runs continuously on a dedicated machine and provides a web UI accessible from any device on the network without installing software. Bambu Studio requires the desktop application on each machine you want to manage from. Bambuddy's file manager, archive and monitoring are accessible from a phone, tablet or any browser without the slicer being installed.

Bambu Studio cannot replace Bambu's cloud for remote printing without VPN or Bambu's own tunnel. Bambuddy's Proxy Mode with Tailscale provides remote access without those options.

The trade-off is maintenance: Bambuddy requires running a server and keeping a Docker container updated. Bambu Studio requires no server but ties you to the cloud for remote features.

Licence, maintenance and security approach

Bambuddy is licensed under AGPL-3.0. This means that anyone who distributes a modified version of Bambuddy, including running it as a hosted service for others, must release the modifications under the same licence. Running it privately for your own printers does not trigger this requirement.

The Python backend uses FastAPI and SQLAlchemy with aiosqlite for SQLite or asyncpg for PostgreSQL. The requirements.txt holds fastapi at below 0.136.0 due to a supply-chain concern with the fastar dependency in 0.136.x, documented in inline comments. sqlalchemy is pinned at 2.0.38 or later because below that version the SQLite driver rejects pool_size and max_overflow arguments. pydantic-settings is pinned at 2.14.2 or later to address GHSA-4xgf-cpjx-pc3j.

The last push was on 2026-09-26, and a daily beta build (v1.2.6b1-daily.20260927) was published on 2026-09-27. The project is under active development with multiple minor releases in September 2026 alone.

Editorial conclusion

Bambuddy is the right tool for Bambu Lab owners who are uncomfortable with mandatory cloud dependency, want to manage more than one printer from a single interface, or need remote printing from outside their local network without Bambu's own tunnel. The Docker installation is the practical path; the compose file is documented and handles the network mode differences between Linux and macOS or Windows. The H2-series limitation is real: prints started from Bambu Studio's Print button archive without thumbnails or filament data, and the only workarounds are starting prints from Bambuddy itself, using OrcaSlicer, or using Bambu Studio's Send button with External storage selected. Before deploying it, verify your printer model is in the list of supported models in the project's wiki at wiki.bambuddy.cool, because the README focuses on A1, X1 and P1 series behavior with notes for H2-series specifically. The last push was on 2026-09-26 and daily beta builds were being published as of 2026-09-27.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. maziggy/bambuddy on GitHub
3. Project website
4. README
5. Releases