A self-hosted stack for a small print farm
Combine a shared model library, local printer controllers, Spoolman, notifications, and backups for a small farm without per-printer SaaS fees.
With several printers, the hard part is often remembering which file to run and what happened last time. A printer dashboard shows the machines. It does not necessarily keep the source model, sliced revision, result, and material record together.
PrintStash can provide that shared record on your own server. Since v0.11.0 it also queues G-code across the fleet with manual, default-printer, or least-busy routing, so a workshop can either let people pick jobs themselves or let the router place them. Order states and customer records still need separate software.
Give each model a proven revision
Store the source file and the useful G-code revisions on one model. Add a short note when the reason for a new slice is not obvious, such as a brim added for corner lift or a slower outer wall for a visible face.
After testing, mark the revision that should normally be used as recommended. Revision outcomes can record known_good, needs_test, failed, or archived. Successful jobs may promote a revision to known good when that setting is enabled, but they do not overwrite a manual failed or archived result.
This gives the next operator a concrete starting point without relying on a filename such as part-final-actually-final.gcode.
Connect printers according to their provider
Moonraker, PrusaLink, OctoPrint, Bambu LAN, and supported Elegoo printers can report live state and accept common controls. Other operations vary:
- Moonraker supports upload, remote inventory, raw G-code, emergency stop, and measured filament data.
- PrusaLink and OctoPrint support upload and remote file inventory, but do not return measured filament use to PrintStash.
- Bambu LAN supports local status, controls, upload, and opt-in start, but not remote inventory.
- Elegoo support can upload a slice, start it, and control the job, but does not browse remote inventory. Upload runs over plain HTTP, independent of the SDCP/MQTT control channel.
Check the compatibility matrix before planning the workflow around a provider-specific action.
Use history for estimates and quotes
Slicer estimates are useful before the first print. Completed Moonraker jobs can add measured duration and filament use to the history. After several runs, those records are a better reference for lead time and material use than the estimate alone.
PrintStash can calculate estimated cost from material profiles. With Spoolman connected, a job can use the selected spool’s price and material properties. Measured write-back to the spool is Moonraker-only, and the printer must not already be decrementing the same usage through another integration.
The cost guide explains what is measured and what still needs to be added manually.
Send useful notifications
Notifications can report completed, failed, and cancelled jobs, plus printers going offline. Channels include generic webhooks, Discord, Telegram, and ntfy. Configure only the events that require attention so a busy channel does not become background noise.
Delivery is at least once, so webhook receivers should deduplicate the Idempotency-Key. URLs that resolve to private or loopback addresses are blocked by the SSRF guard. A self-hosted Home Assistant or n8n endpoint therefore needs a safe public relay or another integration path.
Back up the operational record
A full backup contains the database, managed blobs, thumbnails, and a manifest. It can also be mirrored to S3-compatible storage. Shared-volume source files are not copied into the archive, so back up the NAS separately.
PrintStash creates backups on demand. For a schedule, have cron, systemd, or another automation obtain a JWT and call the backup API. Restore one archive on a test stack before trusting the routine.
Add the operator workflow
Use PrintStash for the library, revision choice, printer file handoff, and history. Keep OctoPrint, Fluidd, Mainsail, or the printer’s own interface for webcams, macros, calibration, and detailed machine control.
For a small farm, that division is often enough. Job routing and maintenance windows are handled by the fleet queue. Camera-based failure detection and order management are not, so those still need a purpose-built farm tool. Self-hosted print farm management for Klipper compares the options for each layer.
The companion print farm workflow guide follows one job from revision choice through printer selection, first-layer checks, and recorded completion.