Bambuddy: Self-Hosted Bambu Lab Control Without the Cloud

Bambuddy is an open-source (AGPL-3.0) control panel for Bambu Lab printers that you host yourself: it talks to the printer directly over MQTT and FTPS, keeps a searchable 3MF archive of every job, and lets you print from anywhere without a Bambu cloud account.

It's a young project moving fast. The maziggy/bambuddy repo was created on November 28, 2025, and as of August 9, 2026 it has 2,756 stars, 361 forks and 124 open issues. The latest stable release is v1.2.5.2 (August 2, 2026), with daily beta builds on top — v1.2.6b1-daily.20260808 at the time of writing. In eight months it went from 0.1.x to 1.2.x, which is fast enough that a couple of the screenshots below are already a release or two behind the current UI.

What follows isn't a sales pitch. It covers what Bambuddy actually does, what you give up when you switch, how to install it with Docker, why remote printing wants a real server rather than a Pi behind NAT, and the gotchas that bite in week one. Every number comes from the repo, the docs or the issue tracker, with links.

Why self-host when Bambu already has a cloud

The practical reason is ownership of your own data. Every job you send through Bambu's cloud lives on someone else's servers, and the print history, thumbnails and statistics that go with it aren't yours to query. Self-hosting flips that: the archive sits on your disk, the API is open, and nothing depends on a vendor relay staying up.

The other reason is community pushback. In May 2026 the Software Freedom Conservancy laid out its AGPLv3 complaints against Bambu Lab, and Hackaday's June 13, 2026 write-up ties that directly to the project's motivation: a closed architecture plus heavy-handed legal behavior is exactly what pushes people to build their own tools.

Worth being precise about what this is: Bambuddy drives your own printer, on your own LAN, over a protocol the manufacturer exposes with a toggle called Developer Mode. The only thing it adds is that the server in the middle is yours.

For Klipper and OctoPrint machines, the same "reach my printer from another network" problem is solved by tunnels and private meshes — we covered those separately in remote access for 3D printers. Bambu Lab runs a closed ecosystem, so here Bambuddy is that bridge.

What you give up, and what to do before switching

This is the section to read before you spin up a server. Moving to Bambuddy isn't free — you trade app convenience for control, and a few familiar things stop working.

You need a Bambu cloud account at least once

Out-of-the-box setup on any Bambu Lab printer runs through Bambu Handy or Bambu Studio with a cloud login and a firmware confirmation. There's no way around it — it's the manufacturer's onboarding flow, and only after it does the local-only option appear in the printer menu. Commenters on the Hackaday piece call this out as the project's built-in contradiction: to escape the Bambu account, you first have to create one.

Developer Mode vs plain LAN Only Mode

People mix these up constantly. LAN Only Mode by itself cuts the cloud, but third-party software only gets read access — it can't drive prints or move files. Full local control comes from Developer Mode, a separate toggle that only appears once LAN Only Mode is on. The README states it plainly: "Standard LAN Mode (without Developer Mode) only allows read-only monitoring."

On warranty: Bambu Lab has never declared Developer Mode grounds for voiding it — it's a stock menu toggle, not custom firmware. But while it's on you're off the cloud, off Bambu Handy, and outside the usual "let me look at your cloud logs" support path. HowToGeek puts it more bluntly: turning on LAN and Developer mode "locks you out of its mobile app entirely." If you're wondering how firmware updates work in local mode, see our Bambu Lab firmware guide.

An SD card and one slicer setting

Two requirements that Bambuddy won't run without, and when either is missing the cause isn't obvious. First: an SD card must be in the printer — file transfer, print starts and archiving all go through it. Second: in Bambu Studio or OrcaSlicer, enable "Store sent files on external storage" under Device → Print Options. Without it the printer doesn't keep the 3MF it received, so Bambuddy has nothing to parse: no thumbnails, no 3D preview in the archive.

What Bambuddy actually does

The fastest way to grasp the scope is demo.bambuddy.cool: your own instance spins up in about ten seconds, the session lasts 30 minutes, printers are simulated, no signup. Here's what that interface does on a real server.

3MF archive, full-text history and re-printing

Every job sent to the printer lands in the archive with its metadata: plate thumbnail, layer count, layer height, filaments used, duration, grams consumed and estimated cost. There's duplicate detection, full-text search, tags, side-by-side archive comparison and an in-browser 3D preview built on Three.js. Any model printed more than once gets an "N prints" badge, and clicking it opens the per-archive log: every run as its own row with date, status, filament and failure reason. A failed 10 g retry never overwrites the original successful 100 g print — both stay visible and the quick stats add up to 110 g.

Re-printing from the archive does the thing the stock software doesn't: AMS slot remapping. Bambuddy matches the job's filaments against what's actually loaded, flags a "Color mismatch" when they don't line up, and lets you reassign slots by hand. Multi-plate projects and the separate nozzles on H2D and H2D Pro are handled too.

Server-side slicing

The heaviest feature by far, and the most convenient. You run a small sidecar container called slicer-api next to Bambuddy, with OrcaSlicer or Bambu Studio inside it in headless mode. After that a Slice button shows up in the file manager, the archive and on MakerWorld imports: drop an STL from your phone, hit Slice, and a ready .gcode.3mf appears in the same folder. Profiles come from a .bbscfg preset bundle exported out of Bambu Studio, so instead of juggling JSON you pick a printer + process + filament triplet from a dropdown. It'll also re-slice an existing archive for a different printer — including across the single-nozzle to dual-nozzle boundary, auto-rearranging parts laid out for a 256×256 mm bed so they land safely on a 350×320 mm one with its per-nozzle dead zones.

On top of that sit pipelines: save the whole "printer + process + per-slot filaments + bed type" recipe once and apply it to any file in one click. A pipeline can target a printer class ("any X1C") instead of one machine, and fan out up to N copies for the scheduler to distribute. If you're still dialing in your profiles, start with our OrcaSlicer settings guide — those profiles import here directly.

Monitoring, cameras and history charts

Status arrives over WebSocket, no page refresh. The camera is handled cleverly: the printer only serves one upstream connection, so Bambuddy pulls it once and fans it out to every open tab, card and floating viewer — otherwise a second viewer would simply kick the first. For farms there's a Cam Wall: cards turn into a grid of tiles, the first few stream live (four by default, configurable), the rest fall back to periodic snapshots, and off-screen tiles pause entirely so a Raspberry Pi install stays sustainable.

Bambuddy logs nozzle, bed and chamber readings once a minute and plots them with 6h / 24h / 48h / 7d ranges, showing current, average, min, max and the target overlay. AMS humidity and temperature get the same treatment. Then there's the statistics dashboard: success rate, time-estimate accuracy, filament usage by type, kWh consumed and cost per print, with CSV and Excel export.

AMS: humidity, drying and spool tracking

Drying on AMS 2 Pro and AMS-HT can be started, monitored and stopped from the browser, with filament-based presets, automatic PSU detection and HMS power-error reporting. Auto-drying kicks in between jobs once humidity crosses a threshold — and the threshold is per filament type — for example nylon at 20%, PLA at 60%, ASA at 30%. A mixed unit uses the strictest threshold of whatever's loaded. On capable firmware (H2D 01.03.00.00+, H2C / H2S / P2S / H2D Pro 01.02.00.00+, X2D / A2L 01.01.00.00+, X1C 01.11.02.00+) drying can even continue during a print, with the temperature automatically capped 5°C below the idle preset and never under 40°C so spools in a hot enclosure don't soften.

Remaining-filament tracking runs through Spoolman sync: each spool is bound to an AMS slot, usage is deducted per print, and fill level shows on the card. For the why and the temperatures, see our filament drying guide; for the units themselves, our AMS troubleshooting guide.

Timelapses, projects and maintenance reminders

The built-in timelapse editor trims clips, changes speed from 0.25× to 4× and layers in an audio track; on P1-series printers the AVI is converted to MP4 automatically. Projects group the parts of one build into a single card with a "22 of 34" progress bar. And the maintenance section counts each printer's runtime in hours and reminds you per interval: lubricate the linear rails, check belt tension, clean the nozzle, replace the HEPA filter — each with its own counter.

Supported printers

That's the entire current lineup, from the cheapest bedslinger to the dual-nozzle machines. The interface ships in 13 languages — the repo carries locale files for German, Spanish, French, Italian, Japanese, Korean, Brazilian Portuguese, Turkish, Ukrainian, both Chinese variants and Russian alongside English.

Installing with Docker, step by step

Docker is the most predictable route: images are built for linux/amd64 and linux/arm64, so the same command works on a rented server, a home mini-PC, a NAS, a Raspberry Pi 4 or 5, and an Apple Silicon Mac. The web UI comes up on port 8000.

Step 1: Enable Developer Mode on the printer

On the printer screen: Settings → Network → LAN Only Mode, turn it on. A Developer Mode toggle appears next to it — turn that on too. The printer displays an Access Code, exactly eight characters; write it down. Grab the IP address from the same network menu and the serial number from device info. You'll need all three when adding the printer.

Step 2: Let the slicer write files to the SD card

In Bambu Studio or OrcaSlicer, open the Device tab for your printer and enable Store Sent Files on External Storage under Print Options. Five seconds of work — skip it and your archive will collect filenames with no thumbnails and no model preview.

Step 3: Bring Bambuddy up with one command

The maintainer ships an interactive script that asks for install path, port, bind address and timezone, downloads docker-compose.yml, writes a .env and starts the container:

If you'd rather not pipe someone else's script into a shell without reading it first (good instinct), the manual route gets you to the same place — grab the compose file from the repo and bring it up.

Both scripts accept --yes to take all defaults plus --path and --port for automation. Updating later is two commands: docker compose pull && docker compose up -d. Note that Docker installs can't use the in-app updater — command line only.

Step 4: Host networking vs bridge, and why it matters

The shipped compose file uses network_mode: host on purpose: SSDP printer discovery needs L2 multicast, which Docker's default bridge network doesn't carry. In host mode printers are found automatically, camera streaming works, and you never list a port.

Bridge mode is mandatory in two situations. The first is Docker Desktop on macOS and Windows, where containers live inside a Linux VM and host mode connects you to that VM's network instead of yours. The second is multi-service Linux hosts — NAS boxes, Synology DSM, Unraid, a shared homelab machine — where another container already holds the ports Bambuddy wants. Both lose automatic discovery, so you add printers by IP, and both need the ports listed explicitly.

The passive-data range is sliced ten ports per virtual printer: VP 1 gets 50000-50009, VP 2 gets 50010-50019, and so on. Expose only what you use. Proxy mode is the exception — it needs the full 50000-50100 range, because it transparently forwards the real printer's entire FTP data range rather than Bambuddy's own slice.

Step 5: First login and adding a printer

Open http://your-server:8000. On Linux with host networking localhost works too; on Docker Desktop it doesn't, so use the machine's address. Head into settings first: pick language, timezone, currency, electricity cost per kWh and default filament cost per kg — those last two drive every number in the statistics dashboard. The same page sets AMS humidity thresholds (green up to 40%, orange to 60%, red above by default) and sensor history retention, 30 days out of the box.

Then hit Add Printer. In host mode it's probably already discovered over SSDP and just wants the access code. In bridge mode add it manually: IP, serial, access code, model. Authentication in Bambuddy is optional, but turn it on immediately — you get permission groups (Administrators, Operators, Viewers by default), two-factor auth via TOTP or emailed code with ten single-use backup codes, and OIDC single sign-on if you run an identity provider.

Step 6: If you're not using Docker

A native install on Linux or macOS needs Python 3.10+ (3.11 or 3.12 recommended). There's an interactive install/install.sh that detects your package manager, builds the frontend with Node.js 22 and registers a systemd or launchd service. Windows gets its own path: a self-contained .exe installer that bundles Python 3.13, the built frontend and ffmpeg, and registers Bambuddy as a Windows service. Data lives in C:\ProgramData\Bambuddy\, and updating means running a newer installer over the old one.

If you hand-write a systemd unit, two lines save you hours. First, AmbientCapabilities=CAP_NET_BIND_SERVICE: the virtual printer binds ports 990 and 322, both below 1024, which an unprivileged service can't do. Leave it out and Bambuddy starts and looks healthy while the virtual printer's sockets silently never open — the only trace is one line in journalctl. Second, run with --loop asyncio: uvloop can truncate virtual-printer FTP uploads on slow storage.

Proxy mode: printing from anywhere without Bambu's cloud

This is the feature that justifies putting Bambuddy on a server rather than a shelf. Bambuddy can impersonate a Bambu Lab printer — a virtual printer that your slicer sees as the real thing. There are four modes, and three are about storage: Immediate archives the received file straight away, Review holds it for manual approval, Queue archives it and adds it to the print queue. The fourth, Proxy, stores nothing and transparently relays traffic to a real printer instead.

Under the hood it's a transparent TCP proxy. FTP, the file-transfer tunnel and the camera stream pass through with end-to-end TLS all the way to the printer — Bambuddy never decrypts them. Only MQTT is terminated, and only because it has to be: the messages carry IP addresses that need rewriting, otherwise the slicer would try to reach the printer's LAN address, which doesn't exist from outside. You authenticate with the printer's own access code — no extra credentials to manage.

Why this wants a server, not a Pi behind NAT

The whole scheme depends on your slicer being able to reach Bambuddy from wherever you are. A Pi behind a consumer router usually can't offer that: most home connections no longer come with a routable public address, and even when they do you'd be forwarding eight separate entries (3000, 3002, 990, 8883, 6000, 322, the 2024-2026 range and the 50000-50100 range) straight to the open internet. Two sane options follow.

• A private mesh between your own devices. Laptop and server land on the same encrypted network, nothing is exposed publicly. Simplest option for most people.
• A rented server with a stable public address. Bambuddy lives there, the printer connects to it, and the slicer always uses the same address. Worth it once you have several printers or they're not where you are.

The certificate step everyone skips

Bambu Studio and OrcaSlicer don't validate printer TLS against the system trust store — they use a bundled printer.cer file containing Bambu's own CAs. Bambuddy's virtual printers use a self-signed CA, so you have to append its certificate to that file by hand. Skip it and the slicer throws an unhelpful Connect <name> failed! [SN:<###>, code=-1] that tells you nothing about the cause.

Download the cert with the button under Settings → Virtual Printer (the card also shows its SHA-256 fingerprint so you can verify later). Append it from a terminal rather than a GUI editor: TextEdit on macOS and Notepad on Windows will happily mangle a PEM file with re-encoding and smart quotes.

You'll repeat this after every slicer update (installers restore the original file), on every fresh Bambuddy install (each generates its own CA), and whenever you move to a different host. With several hosts it's easier to copy the virtual_printer/certs/ directory from the first one so they share a CA. After editing, quit the slicer completely — not just close the window.

If the printer still doesn't show up, don't guess — every virtual printer card has a stethoscope button that runs a built-in setup check. It separately verifies that the VP is enabled, that its services started, that the bind interface still matches a live address (a DHCP lease change is a classic cause of "it vanished"), that an access code is set, that the target printer is reachable, that something is genuinely listening on 990, 8883 and 3002, and that the certificate chain exists on disk.

A private mesh between your own devices

Bambuddy ships an optional Tailscale integration, and it's refreshingly modest. Flip the per-VP toggle and Bambuddy queries the host's local tailscaled daemon, pulls the 100.x.x.x address and MagicDNS name, and displays them right on the card with a copy button so you know what to paste into the slicer. The status is cached for 60 seconds. Bambuddy itself never joins your tailnet and runs no sidecar of its own. Per Tailscale's May 13, 2026 write-up, the whole integration is about 200 lines of Python.

In practice: your laptop and your server see each other directly, no port forwarding, no dynamic DNS, nothing exposed publicly, and the slicer connects to a 100.x.x.x address exactly as it would to a printer on your LAN. Project author Martin Ziegler frames the motivation simply — the request he kept getting was how to print to a home Bambuddy from a work laptop without putting anything on the public internet.

One limitation to know up front: the mesh's automatic HTTPS doesn't help the slicer, and you still have to append Bambuddy's CA to printer.cer. Two independent reasons, both on the slicer side — it validates certificates only against the bundled Bambu CA store, and its Add Printer dialog accepts an IP address, never a hostname. That pair is also why the original idea of giving each virtual printer its own signed certificate was never implemented.

Sizing the server: how much RAM and disk you actually need

Be warned: Bambuddy publishes no official system requirements. Not the README, not wiki.bambuddy.cool, not the project site — they list target platforms (Docker, Pi 5, NAS, mini-PC) and the database choice (built-in SQLite or external PostgreSQL) and stop there. So the sizing below is inferred from indirect evidence, but the evidence is specific.

• Server-side slicing is the heavy load. It's a full headless OrcaSlicer computing toolpaths and emitting G-code, not a quick utility — a multi-plate project holds CPU and memory for a while.
• Cameras and virtual printers have historically eaten gigabytes. In issue #2734 (opened July 31, 2026, closed August 2) memory grew unbounded: ~14.5 GB on July 27 and ~15.7 GB on July 31 on a 31 GB host, over one to four days of uptime. The kernel OOM killer fired seven times in three and a half hours and took out unrelated processes — navidrome, jellyfin and someone else's camera stream. The reporter noted it resembled issue #776, closed as fixed back in March 2026, i.e. a regression.
• Open ports cost memory too. That's the 1,001-port range and ~3.5 GB of Docker helper processes from issue #1646.
• Disk accumulates for months. The archive keeps every 3MF with thumbnails, plus timelapses, plus finish photos, plus sensor history (30 days by default, configurable).

Both issues are closed, but the lesson holds: the parts that touch video and virtual printers are memory-hungry, and headroom isn't a luxury. Practically, that gives two tiers. For one or two printers running monitoring, archiving and proxy mode — with slicing still done on your desktop — 2 GB of RAM and 30 GB of disk is enough. Turn on server-side slicing, run several virtual printers at once, or grow toward a farm, and you want 4 GB and 60 GB. A 1 GB instance will technically boot and then fall over the first time the slicer and a camera run together.

CPU matters less than you'd think for monitoring and archiving — a single modern core handles it — but slicing scales with cores, so a second core is the cheapest upgrade if you plan to use the Slice button often. Same logic we applied in our guide to running a self-hosted 3D printing server: light workload on the small box, heavy workload one tier up.

Gotchas and limitations

CVE-2026-25505 and why you don't expose the UI

On February 2, 2026 Bambuddy disclosed CVE-2026-25505, scored 9.8 out of 10. Two parts. First, the JWT signing secret was hardcoded in the source as bambuddy-secret-key-change-in-production, meaning anyone could forge an admin token for any instance running the default key. Second, many API routes didn't check auth at all — a request to /api/v1/system/info with no Authorization header returned 200 and system details.

Fixed in 0.1.7, over six months ago, and the current 1.2.5.2 is far past it. But the episode sets three rules worth following on any version. Keep it updated rather than install-and-forget. Don't put the web UI on the internet without your own auth on a reverse proxy — Bambuddy does emit strict anti-framing headers by default, but that's not a substitute for access control. And when you hand out API keys for Home Assistant or webhooks, scope them tightly: a key acts on behalf of its creator, and the optional Bambu cloud-access scope is off by default for a reason.

Worth noting: the maintainer is openly recruiting a contributor to watch security on the dev branch — the ad sits right in the README. That reads as a good sign rather than a bad one, but it's a more honest signal about project maturity than any marketing line.

One control connection at a time

The most common complaint, and it lives in the printer firmware rather than in Bambuddy. Most Bambu machines accept a single upstream connection, and if Bambuddy runs around the clock, that connection is Bambuddy's. Hackaday commenter doobs put it exactly right: the printer can only be connected to one thing at a time, and since Bambuddy is always on, it's the one. You can't work in the official slicer in parallel — you switch by hand. It's also why Bambuddy fans a single camera stream out to every tab: there is no second camera connection to be had.

The FTP data channel isn't encrypted on the slicer side

A non-obvious detail the Bambuddy docs are upfront about. Bambu Studio's FTP implementation negotiates PROT P but then sends the file data in cleartext anyway. The MQTT control channel is fully TLS-encrypted, so commands and status are safe. The practical consequence: your 3MF files travel unencrypted between slicer and Bambuddy, which makes putting proxy mode directly on the open internet a bad idea. Wrap it in a private mesh between your own devices, or a tunnel — the options are covered in our remote access guide.

Bambu Lab only, and MakerWorld only

Bambuddy is single-brand by design: Klipper machines, OctoPrint setups and other manufacturers simply aren't visible to it. A mixed shop needs two tools. Model imports are similarly narrow — the integration covers MakerWorld only, so Thingiverse and Printables mean downloading and re-uploading by hand. That's open feature request #2793, filed August 8, 2026, whose author helpfully linked Thingiverse's official REST API.

No built-in failure AI — but it can call one

Don't confuse the two. Bambuddy has no model of its own for spotting spaghetti on the camera feed. What it does have is an optional integration with a self-hosted Obico ML API: it watches the running print's feed, smooths the score over time (30-frame warmup, EWM and rolling means) and fires one configurable action per print — notify, pause, or pause and cut power via a smart plug. So you can get failure detection, but you host and maintain the model separately; we walk through that in our guide to a self-hosted printing server with Obico. There's also a simpler non-AI safeguard: build-plate empty detection refuses to start a print if objects are still on the bed.

Open bugs worth knowing about

As of August 9, 2026 the tracker holds 124 open issues, and the overwhelming majority are feature requests rather than breakage. The real defects that might reach you:

• #2796 (Aug 8, 2026) — the archives API always returns plate_id: null even when the column is populated; on the reporter's instance 181 of 257 rows carry a real value. Only affects API consumers, invisible in the UI.
• #2780 (Aug 6, 2026) — on some printers the archive captures only the filename and none of the other data. Reproduced on P2S and H2C when sending through a proxy-mode virtual printer, while the same owner's other machines are fine.
• #2774 (Aug 6, 2026) — AMS HT drying: the user picks PLA in Bambuddy, which correctly sets 45°C for 12 hours, but the printer panel keeps showing the previously set Support for PLA/PETG profile, because that profile isn't in Bambuddy's dropdown to switch back to.
• #2761 (Aug 4, 2026) — in unusual topologies (Kubernetes, a separate proxy in front) the slicer is told the bind address rather than the address it actually reached. The request is for a way to set it explicitly.

For exactly these cases Bambuddy has in-app bug reporting: submit from the UI with a screenshot, an interactive debug-log capture (start logging, reproduce at your pace, stop and submit) and system info, with IPs, serials and credentials stripped from the logs. There's also a live MQTT log viewer, which is the fastest way to see what the printer is actually replying.

Scaling to a farm

Hackaday pegs Bambuddy's working range at "one to forty printers" — that's the author's estimate, not a documented limit; nothing in the code caps the machine count. The maintainer states it more broadly: from one A1 to an entire print farm.

Everything Bambuddy starts — a send from the file manager, a re-print from the archive, an upload straight from a printer card, a scheduled job — flows through one queue. That means every print has an owner, shows up in one list, gets a filament-deficit check and can be cancelled from a single place. The queue has three tabs (queue, history, timeline), items reorder by drag and drop, and multi-plate projects collapse into a single group row automatically.

The scheduler does two things that matter at scale. It can queue a job as "ASAP, whenever a printer frees up" with no fixed time. And it supports "only start if the previous print succeeded" — so a failed part stops the batch instead of producing twenty more of the same defect. Add the "power off printer when done" checkbox and you have the basis for overnight runs.

Smart plugs are the other half of the automation. Bambuddy speaks Tasmota, MQTT, REST and Home Assistant: it shows live wattage (218 W across two plugs in the screenshot), totals kWh for today, yesterday and all time, and converts them to money using your electricity rate. Each plug can be linked to a specific printer and switched on when a print starts and off when it finishes.

How far that goes shows in an example from HowToGeek: the owner of a 70-plus printer farm modified Bambuddy so chamber lights switch off five minutes into a print, come back on when it completes, and flash on error. The result is that the status of an entire row is readable at a glance, without looking at a single screen. The source is AGPL-3.0, so that kind of modification is both legal and technically straightforward. The same piece adds a fair caveat: Bambuddy is "not a drop-in replacement, though it does offer a lot of similar functionality."

For fleets of identical machines there are class-targeted pipelines and multi-copy fanout: slice once, dispatch 12 copies across every free X1C, choosing Spread for the fastest wall-clock time, Single printer to minimize color-change waste, or First N for one each. A Pipelines tab tracks every run, and Retry failed re-runs only the copies that didn't complete — successful ones are never reprinted.

What it costs to run

The software is free and stays that way — AGPL-3.0 requires it. The project runs on donations: GitHub Sponsors tiers from $5 to $300 a month plus one-off Ko-fi tips, with Patron tier ($35/mo) and above voting on the quarterly roadmap. So the only mandatory line item is the box it runs on.

If you already own a Raspberry Pi 5 or a NAS, the marginal cost is close to zero — arm64 images are official, and the only real expense is the electricity the box draws, which is a rounding error next to a printer pulling 200 W. If you rent a VPS instead, a 2 GB / 30 GB instance is the entry point for monitoring, archiving and proxy mode, and a 4 GB / 60 GB dual-core one covers server-side slicing and a growing farm. Either way you're comparing that against a single spool of decent filament, or against one twelve-hour print that failed unnoticed at hour eleven.

One cost that's easy to forget: disk. The archive keeps every 3MF with its thumbnails, plus timelapses and finish photos, and it grows monotonically. Budget for it, prune old archives occasionally, and keep the sensor-history retention (30 days by default) where you actually want it.

Running it: updates, backups and notifications

Daily beta builds exist but carry their own tags and never land on latest, so a stable install won't drift onto a beta by accident. Updating in Docker is docker compose pull && docker compose up -d. If your compose file pins a specific version, change that line first — otherwise pull just re-fetches the same tag. Bambuddy prints the exact command in its Updates panel with a copy button.

Backups run on a schedule — hourly, daily or weekly — with retention management and NAS-mountable output. Separately you can push cloud profiles, K-profiles and settings to GitHub on a schedule. Restore happens from the UI, or through the standard pg_dump and pg_restore if you moved to external PostgreSQL.

Notifications are the reason a lot of people install a panel in the first place. Eight providers: Telegram, Discord, WhatsApp, email, Pushover, ntfy, Home Assistant and plain webhooks. Events are toggled individually — start, complete, failed, stopped, progress milestones at 25/50/75%, printer offline, printer error, low filament, maintenance due, AMS humidity or temperature over threshold. There are quiet hours, a daily digest, and editable message templates.

Last but genuinely useful: the maintenance section. It tracks each printer's runtime in hours and keeps a separate counter per procedure — lubricate rails, belt tension, clean nozzle, clean build plate, carbon rods, PTFE tube, HEPA filter — each showing what's left as "86h" or "3 months". Pleasant with one printer, the only way to stay on schedule with ten.

FAQ

Sources

• maziggy/bambuddy repository — README, releases, supported printers (figures verified August 9, 2026)
• wiki.bambuddy.cool — installation, virtual printer, ports, certificate import, setup check
• GHSA-gc24-px2r-5qmf — CVE-2026-25505, published February 2, 2026
• Hackaday, June 13, 2026 — overview plus reader comments on the single-connection limit
• XDA-Developers — hands-on with a Bambu Lab P2S and a frank list of downsides
• MakeUseOf — who Bambuddy is not for
• HowToGeek — the 70-plus printer farm and its chamber-light automation
• Tailscale blog, May 13, 2026 — how the integration works and where it stops
• Project issue tracker: #2734 (memory growth), #1646 (Docker helper processes), #2796, #2780, #2774, #2793, #2761