PrintStash v0.9.0: five printer providers

PrintStash v0.9.0 expanded printer support from Moonraker and Bambu LAN to five provider types. It added beta OctoPrint, PrusaLink, and Elegoo Centauri connections, plus guided Moonraker setup for Elegoo Neptune 4 printers.

The release also moved provider behavior behind a common capability matrix. Buttons and API diagnostics could then reflect what a configured printer actually supports.

OctoPrint and PrusaLink

The beta OctoPrint provider connected to a local OctoPrint or OctoPi instance with an API key. It supported live status, G-code upload and explicit start, remote file inventory and deletion, and pause, resume, and cancel controls.

The beta PrusaLink provider covered local FDM printers without routing through Prusa Connect. Current installations used Digest username and password authentication, while older versions could use an API key. Its initial capability set matched OctoPrint.

Neither provider returned measured filament consumption to PrintStash. The compatibility matrix keeps that and other provider limits explicit.

Elegoo printers

Elegoo Neptune 4, Pro, Plus, and Max received a guided preset backed by the stable Moonraker provider. They retained the standard Moonraker file, control, and measured-job workflow.

The beta Elegoo Centauri provider used local SDCP over WebSocket for the original Carbon and an access-code-protected local MQTT connection for Carbon 2. Both reported status and could start an existing printer-side file, pause, resume, or cancel.

Upload and remote file inventory stayed disabled for Centauri printers because the firmware did not expose a confirmed file API suitable for those operations.

Bambu LAN upload and opt-in start

Bambu LAN gained plain-text G-code upload to the printer’s local cache over implicit FTPS. A separate local MQTT command could start the uploaded job.

Upload-only remained the default. The user had to select Start print immediately for an automatic start. PrintStash checked that the printer reported idle or ready before creating the transfer job, avoiding a stuck uploading record for a busy or unreachable printer.

Bambu remote inventory and deletion remained unavailable.

Capabilities drive the interface

Every provider declared whether it supports status, upload, start, job controls, remote inventory, raw G-code, and measured filament. The frontend derived control availability from those values and explained unsupported actions.

A shared conformance suite checked registration, required credentials, unsupported-operation rejection before network access, and common error handling. This reduced provider-specific branches in the frontend and API.

Mixed-provider sends remained possible. Upload-only printers stayed selectable, while Send & Print became unavailable when any selected provider could not start the uploaded file.

Reliability and performance

• Connection and subscription retries used bounded exponential backoff.
• A recovered provider cleared its stale offline or error state after a successful update.
• Bambu connection failures reached the common printer hub instead of leaving a false online state.
• Duplicate Add printer submissions were ignored.
• Unchanged live progress writes were coalesced to five-second intervals.
• Three consecutive job-sync database failures opened a per-printer circuit breaker with increasing retry delays.
• Theme changes stopped applying transitions to every element and pseudo-element.
• Printer, Statistics, Profiles, Settings, and Organize pages shared one width and scroll container.

Node.js 24 became the pinned frontend and release-build version.

Upgrade with:

docker compose pull
docker compose up -d

The v0.8.5 to v0.9.0 diff contains the full UI and implementation changes.