I went looking for something pretty specific: a way to automate AMS drying instead of eyeballing humidity levels, and some kind of failure detection that didn’t require me to babysit a camera feed all day. I wasn’t trying to overhaul my whole printer setup — I just wanted those two gaps closed.
What I found instead was Bambuddy, and it turned out to solve both of those problems while also being built around something bigger: getting Bambu Lab printers off the company’s cloud entirely. I wasn’t shopping for that, but once I saw what it actually was, it was hard not to care.
If you own a Bambu Lab printer, you already know the deal: every print job, every camera frame, every status update routes through Bambu’s servers by default, even though the printer is sitting on your own network. Starting around January 2026, Bambu Lab tightened that ecosystem further, requiring its own authorization for things that used to just work locally — on top of ongoing community friction over alleged AGPLv3 license violations and a rigid legal posture toward third-party tools.
That’s the actual reason Bambuddy exists. Built by a developer who goes by Martin (maziggy), it’s a free, open-source, self-hosted command center that runs in Docker on your own network and gives you full local control — no cloud account, no round-trip to Bambu’s servers, no dependency on infrastructure you don’t own. The AMS automation and failure detection I was originally chasing are in there, but so is a lot more. Here’s the actual rundown of what it can do.
Getting connected: LAN Only Mode and Developer Mode
To use Bambuddy, you put the printer into LAN Only Mode and then enable Developer Mode, which is what allows third-party software to control the printer locally instead of just monitor it. Worth flagging up front: standard LAN mode without Developer Mode is read-only — you see status, but you can’t act on it. Developer Mode unlocks full control but kills Bambu’s cloud features for that printer. It’s an either/or, not a hybrid.
AI failure detection: catching problems before you walk over
This is the feature that solves the “I find out my print failed by walking over and looking” problem. Bambuddy doesn’t run failure detection itself — it hooks into a self-hosted Obico ML API container running on your own network. No Obico account, no cloud calls, no third-party service involved at any point.
Here’s how it actually works under the hood: while a print runs, Bambuddy hands the ML API your printer’s camera snapshot URL every 5 to 120 seconds (10 seconds is the default). The ML API fetches the snapshot itself and runs it through a YOLO-based model, returning confidence scores for things like spaghetti, layer shift, and loose debris. Rather than reacting to any single frame, scores get smoothed using the same exponentially-weighted and rolling-mean math Obico itself uses, with a 30-frame warmup period — so one weird-looking frame from a normal print doesn’t trigger a false alarm.
You control how trigger-happy it is with a Sensitivity setting:
– Low — fewer false positives, but may miss early-stage failures
– Medium — the default, using Obico’s original thresholds
– High — catches problems earlier, at the cost of more false alarms
Once the smoothed score crosses your threshold, Bambuddy fires one of three configured actions, exactly once per print so you don’t get spammed:
– Notify only — sends a printer-error alert through whichever notification platforms you’ve set up
– Pause print — notifies you and sends an MQTT pause command to the printer
– Pause and cut power — pauses the print and turns off any smart plug linked to that printer
That last option matters more than it sounds. A paused print with a hot nozzle and an active heated bed isn’t actually “stopped” — cutting power is the difference between a paused job and a safely shut-down one if you’re not coming home for a few hours.
The detection runs against whatever camera feed the printer is already streaming, onboard or external, so there’s no separate camera hardware requirement just for this feature. The Obico ML container is the one piece that doesn’t come bundled with Bambuddy itself — it’s a separate Docker service you stand up alongside it.
AMS automation: drying that doesn’t require you to remember
Manual AMS drying means noticing humidity creep, or not noticing until a spool’s already given you stringing or poor layer adhesion. Bambuddy automates the entire loop:
– Manual remote drying — start, monitor, and stop drying sessions for AMS 2 Pro and AMS-HT units straight from the Printers page, with filament-based temperature and duration presets or manual control, plus optional spool rotation for even heat distribution
– Queue auto-drying — automatically starts a drying session between scheduled prints when humidity crosses your configured threshold, using the lowest safe temperature across whatever filaments are loaded
– Ambient drying — keeps idle printers’ filament dry based on humidity even when nothing is queued, so spools aren’t absorbing moisture while the printer sits unused
– Power-aware scheduling — reads power constraints directly from the printer firmware; if an AMS unit isn’t getting external power, the drying button disables itself with a tooltip instead of failing silently, and the auto-drying scheduler skips that unit entirely
– HMS error visibility — AMS-related firmware errors (fan failures, voltage issues) show up in a dedicated error panel rather than just a cryptic code on the printer screen
If you’re running AMS 2 Pro or AMS-HT specifically, this closes a real gap — Bambu’s own app doesn’t give you scheduled or ambient drying at all.
Maintenance scheduling: the thing Bambu Handy just doesn’t have
This is one of the more quietly useful features in the whole project, and it’s a complete blind spot in Bambu’s own software. There’s no way in Bambu Handy to get reminded that a nozzle needs swapping or a belt needs tensioning — you’re relying on memory, or finding out the hard way when print quality starts slipping.
Bambuddy tracks cumulative print time per printer right on the dashboard card, and builds maintenance scheduling directly on top of that data. You can define your own maintenance tasks — nozzle changes, belt tensioning, lubrication, whatever your printer actually needs — each with its own icon and its own independent schedule, and every printer in a fleet gets tracked separately rather than sharing one generic reminder. Intervals can be based on either calendar days or actual print hours, which matters more than it sounds: a printer that’s been idle for two months doesn’t need the same maintenance cadence as one that’s been running jobs back-to-back, and hour-based tracking actually reflects real wear instead of just elapsed time.
Once a maintenance interval comes due, it surfaces through the same notification system as everything else — print failures, AI detection alerts, completed jobs — so it shows up wherever you’ve already got Bambuddy alerts configured rather than being yet another thing to separately check. For anyone running more than one printer, this is the difference between maintenance actually happening on schedule and maintenance happening whenever you happen to notice something’s gone wrong.
Filament and spool management: built-in inventory vs. Spoolman
Beyond drying, Bambuddy tracks the filament itself, and this is the one area where you genuinely don’t need a second Docker container if you don’t want one.
Bambuddy ships its own full inventory system out of the box: weight tracking, cost-per-kg per spool with automatic per-print cost calculation, CSV import and export (with a preview-first import flow so nothing writes until you confirm), bulk actions, and NFC tag writing that works with any filament brand, not just Bambu’s. None of that requires Spoolman or any external service — it’s built into Bambuddy itself, no extra container, no extra setup.
Spoolman is still supported as an option, and when it’s enabled Bambuddy’s inventory tab switches over to a built-in interface for Spoolman-managed spools that looks and behaves identically to the native one — same filtering, same editing, same NFC writes, same AMS deep-links. So you’re not losing any UI by switching backends; you’re just choosing where the data lives.
The honest case for each one: the built-in inventory makes sense if Bambuddy is the only print-management tool in your stack — one less container, one less thing to maintain or back up separately. Spoolman makes more sense if you’re already running it for other reasons, like a Klipper or OctoPrint setup that shares the same filament database across multiple machines and software, since Spoolman’s whole pitch is being a shared inventory hub other tools plug into. One real limitation either way: Bambuddy’s automatic Spoolman sync only picks up official Bambu Lab spools with RFID — third-party, refilled, or generic spools get skipped in that auto-sync path, so if you’re running a lot of non-Bambu filament, the native NFC-tag approach is probably the more complete option regardless of which backend you pick.
Rounding out the rest of the filament-management features:
– RFID re-read — manually trigger a re-read if you swap a spool and the AMS doesn’t pick up the change automatically
– Remote load/unload — trigger AMS slot or external spool loading without walking to the touchscreen, including dual-extruder routing on machines like the H2D
Notifications: actually flexible, unlike Bambu Handy
Bambu Handy sends you a push notification through Bambu’s cloud and that’s about it. Bambuddy supports a genuinely wide spread of notification channels: WhatsApp, Telegram, Discord, email, Pushover, ntfy, Home Assistant, and custom webhooks.
Each one is configurable per event type — print started, print finished, print failed, AI failure detected, plate-detection issues, and more — with a few extras worth knowing about:
– Quiet hours and daily digest — bundle non-urgent updates instead of getting pinged constantly
– Customizable templates — include filament usage details, photos, or whatever else matters to you
– Priority levels for ntfy — map specific events to escalation levels (sound, vibration, do-not-disturb override) rather than treating every alert the same
– Plate-detection alerts always go through immediately, even during quiet hours, since those need action before a print starts
– Per-user email — if you’ve got Advanced Authentication enabled for multiple users, each person can get notified about their own jobs specifically
For anyone running more than one printer or wanting alerts somewhere other than a single phone app, this is one of the bigger practical upgrades over stock Bambu software.
Multi-printer and farm management
Even outside a true farm setup, this matters once you’ve got more than one machine: Bambuddy supports anywhere from a single A1 up to a 40-printer fleet, with model-based routing that dispatches jobs based on which printer is idle and has the right filament already loaded. Bambu Handy doesn’t do anything like this.
Other farm-relevant features include a drag-and-drop print queue with time-based scheduling, automatic 3MF archiving with metadata and photo attachments for every print, and smart-plug integration (Tasmota, Home Assistant, MQTT, or REST/webhook) for automatic power-off when a job finishes or a failure is caught.
Remote access without the usual headaches
Bambuddy’s Proxy Mode lets you control a printer from anywhere without port forwarding or a VPN — it acts as a relay between your slicer and the printer, with end-to-end TLS encryption on file transfer and camera streaming, while the printer itself never leaves your local network. If you’re already running Tailscale, it layers in cleanly: Bambuddy can surface your host’s Tailscale IP directly on the printer card.
External cameras (if you ever need them)
The onboard camera is enough for most of this, including AI failure detection, but Bambuddy also supports external cameras over MJPEG, RTSP, HTTP snapshot, or USB/V4L2, with layer-based timelapse and automatic video stitching. Useful for multi-angle setups or if a printer’s built-in stream gets unreliable. One wrinkle: the more advanced RTSPS relay workarounds documented for the X1/P2/H2 series (which stream over port 322) don’t apply to A1, A1 Mini, P1P, or P1S models — those use a different proprietary protocol on port 6000, so that particular fallback isn’t available if the built-in stream on those printers ever acts up.
Installation options: native vs. Docker
Most of the write-ups treat Bambuddy as a Docker-only tool, but it’s not — there are real native installers too. macOS and Linux get a script-based native install (Homebrew handles the macOS side), and Windows has its own native installer that’s genuinely standalone: it bundles an embedded Python runtime, the dashboard, and ffmpeg, then installs Bambuddy as an actual Windows service via NSSM so it starts automatically at boot and runs in the background like any other Windows service. No Docker, no manually launching it after every reboot. One thing to expect on first run: since the installer isn’t yet code-signed, Windows SmartScreen will flag it as unrecognized — you click through “More info → Run anyway” to proceed, which is normal for a smaller open-source project still working toward signing approval.
The native install matters more than it might seem, because of a real Docker limitation: Docker Desktop on both macOS and Windows can’t access LAN multicast traffic, so printers won’t auto-discover through Docker and have to be added manually by IP address. Going native sidesteps that entirely on either platform, since there’s no Docker Desktop networking layer sitting between Bambuddy and your LAN. If you’re running Bambuddy on a spare Linux box or a Pi instead, that limitation doesn’t apply, since Linux Docker can use host networking directly.
So the practical takeaway: running Bambuddy natively on Mac or Windows gets you the smoothest experience, including working printer auto-discovery, with zero Docker footprint for Bambuddy itself. Docker is still fully supported on both platforms if you’d rather containerize everything, especially if you’re already running other self-hosted tools that way — you just inherit Docker Desktop’s networking quirks if you go that route instead of installing natively.
Where Docker still comes back into the picture either way is the companion services. Obico’s ML API has no native installer at all, so AI failure detection means standing up a Docker container regardless of how you installed Bambuddy itself. The good news: that container doesn’t have to live on the same machine as Bambuddy. Bambuddy just hands the ML API a snapshot URL it can fetch over your LAN, so you can run Bambuddy natively on a Windows or Mac machine with zero Docker footprint, and run Obico’s ML API in Docker on a separate Pi or NAS elsewhere on the network — they just need to be able to reach each other over HTTP. That keeps your main machine Docker-free even if you want AI failure detection running.
The actual tradeoff
None of this is plug-and-play, but the Docker footprint is smaller than it first looks. Bambuddy itself can run completely Docker-free via the native installers on Mac and Windows, and the built-in filament inventory means you don’t need a second container just to track spools. The one piece that genuinely requires Docker is Obico’s ML API for AI failure detection — and even that can live on a totally separate machine on your network rather than cluttering up wherever Bambuddy itself runs. You’ll also have to give up Bambu Cloud convenience on any printer you flip into Developer Mode, which is the real non-negotiable tradeoff here. For a single printer, that’s still some setup overhead for features Bambu’s stock software mostly doesn’t offer anyway. For a small farm — or anyone planning to scale past one machine — the automation and fleet management probably pay for that setup time pretty quickly.
I went in looking for AMS drying automation and failure detection. I came out with both, plus a notification system, a fleet manager, and a real answer to the cloud-dependency problem I hadn’t even been thinking about. That’s a pretty good outcome for what started as a narrow search.