Running a Large Farm¶

Bambuddy runs comfortably on a Raspberry Pi with a handful of printers. Past roughly ten machines a few costs stop being negligible, and one of them dominates everything else by an order of magnitude.

This page is about that: what actually scales, what does not, and which knobs are worth turning before you buy a bigger server.

Cameras: the dominant cost¶

How much a camera costs depends entirely on which protocol the printer speaks, and the two families are not close.

Browsers cannot display an RTSP H.264 stream in an <img> element, so for the second family Bambuddy decodes the video and re-encodes it as MJPEG in software. That transcode is essentially the whole bill.

Two measurements contributed by users on their own hardware:

What does not cost you anything¶

Three things are cheaper than people expect, and knowing this saves a lot of unnecessary hardware:

• Idle printers cost nothing. Bambuddy never streams a camera in the background. A stream exists only while something is actually watching it, and is torn down a few seconds after the last viewer leaves.
• Extra viewers cost nothing. Bambuddy opens one upstream connection per printer and fans it out to every viewer. Five people watching the same printer is one stream, not five. (This is also why it works at all — most Bambu firmwares allow only a single camera connection.)
• Off-screen Cam Wall tiles cost nothing. A tile only draws when it is at least 40% visible; scrolled out of view, it stops using the network entirely.

So the load is driven by how many cameras are open at once, not by how many printers you own or how many people are logged in.

Tuning the Cam Wall¶

The Cam Wall is where a large farm usually meets this limit, because it is the one screen that tries to show everything at once. It has two settings built for exactly this, in the popover behind the gear icon:

On a big farm, start at 4 live streams and a 20–30 second snapshot interval, then raise the live count only if the server has headroom.

AI failure detection¶

AI failure detection is off by default. When you switch it on, check the per-printer selection before you walk away: with nothing selected it monitors every printer.

It captures a frame from each actively printing machine on a fixed interval (default 10 seconds, minimum 5) and sends it for inference. On an RTSP farm that is a transcoder start per printer per cycle, around the clock, with nobody watching a screen. On a large farm this is the one camera load that runs unattended, so it is worth being deliberate about:

• Select only the printers that genuinely need watching.
• Raise the poll interval. Failures develop over minutes, not seconds; 30–60 seconds is usually plenty.

Move the database to PostgreSQL¶

Unrelated to CPU load, and just as important at scale.

SQLite allows exactly one writer at a time across the whole database. Bambuddy writes from several places at once — the queue scheduler, archive status updates, runtime tracking, MQTT event callbacks, the energy snapshot loop and the FTP retry loop. On a small setup those writes rarely collide. On a large farm, dispatch and completion events overlap constantly.

When the wait times out, the write fails with:

(sqlite3.OperationalError) database is locked

Some code paths retry that; not all of them do. The result is occasional lost archive status updates and runtime records rather than a visible crash, which is what makes it easy to miss.

Large PostgreSQL farms can also raise the connection pool with DB_POOL_SIZE and DB_MAX_OVERFLOW if you see pool timeouts under load (details and the connection-ceiling arithmetic).

What scales cheaply¶

For completeness, the things that are not worth worrying about:

• One MQTT connection per printer, held open. Light, and mostly idle.
• A 30-second REST fallback poll per printer, covering the handful of fields MQTT does not push.
• Queue, archive, statistics and search. Bounded by activity, not by fleet size.

There are Bambuddy installations running 90+ registered printers. Fleet count on its own is not the constraint — concurrent camera streams and database write contention are.

Sizing checklist¶

If a large farm is loading your server, work down this list in order:

1. Count your open cameras, not your printers. Close viewers and kiosk tabs, and switch the Printers page to card view. Does the load drop? Then it is cameras.
2. Check what is at the top of top or docker stats. Several ffmpeg processes points at cameras; the bambuddy process itself points somewhere else.
3. Check your model mix. A1 and P1 machines are nearly free. If your fleet is mostly X1/X2/H2/P2, the transcode is your ceiling.
4. Lower the Cam Wall live count and raise the snapshot interval — on every browser and kiosk showing a wall.
5. Check AI failure detection is either off or scoped to the printers that need it.
6. Move to PostgreSQL if you are above ten printers and still on SQLite.

What is being done about it¶

The transcode is an architectural limit, not a configuration mistake, and there are two open tracks to remove it:

• #2621 — Intel Quick Sync acceleration. Moves the decode and encode onto the GPU. A working prototype measured roughly 8.5x lower CPU.
• #2706 — H.264 passthrough. Removes the transcode altogether by handing the printer's existing H.264 stream to the browser, which decodes it in hardware. Measured at about 101% CPU down to 1–9%, and 11 Mbps down to 1 Mbps.

The second is the one that makes a large wall of live cameras realistic.

Related¶

• Camera Streaming — stream modes, Cam Wall, kiosk tokens
• PostgreSQL Support — setup, migration, pool tuning
• AI Failure Detection — configuration and scoping
• Supported Printers — which models are in which camera family
• Troubleshooting — symptom-first index