Home

Printorian

A management system for an automated 3D print farm: a customer-facing configurator with transparent pricing, automatic printer assignment and dispatch, and farm-floor operations. Bambu Lab first, brand-neutral by construction.

This wiki is the narrative documentation — how the system works, how it is used, and how it is kept running. The repository keeps the normative documents: docs/ says what is decided, HANDOFF.md says what is true right now, and the issue tracker says what is missing. Where this wiki and the code disagree, the code is right — see Project Status for what is proven and what is not.

---

Start here

If you are	Read
a customer, or writing for one	Customer Workflow → Pricing → Storefront Guide
working the farm floor	Farm Workflow → Console Guide → Post-Production and Packing
running the farm's server	Deployment → Operations → Backup and Restore
writing code here	Installation → Architecture → Development and Governance
trying to understand a word	Glossary

---

The system in one picture

flowchart TB
    WEB["storefront SPA<br/>catalogue · configurator · checkout · cabinet"]

    subgraph lan["Farm LAN"]
        direction TB
        CON["console SPA<br/>dashboard · orders · prep · fleet · materials · journal"]
        API["API — one process, one domain model"]
        WK["workers — seven sweep loops"]
        PG[("PostgreSQL 17")]
        RD[("Redis")]
        PRN["printers<br/>bambu · manual · mock"]
    end

    WEB -->|HTTPS| API
    CON -->|same-origin /api| API
    API -.->|WebSocket| CON
    API --> PG
    WK --> PG
    API <-->|event relay| RD
    WK <-->|event relay| RD
    WK -->|MQTT over TLS · FTPS| PRN

Loading

The API and the workers are separate containers with an in-process bus each. The Redis relay is what carries an event raised by a sweep to a console that is watching; without it the boards load once and then sit still while the farm works. What crosses the WebSocket is an invalidation, never state — the console is told what went stale and asks for it, so a dropped frame costs a refetch instead of leaving two screens quietly disagreeing.

The four rules everything else follows from

1. One backend, one database, one domain model. No mirrored entities, no sync layer. Held up by an import-linter contract.
2. One pricing engine — a pure deterministic function. Transparent breakdowns and per-option deltas fall out of it for free.
3. Drivers never simulate silently. A disconnected printer reports Offline and raises an alert. It never invents data. Generalised: a null reading is "not measured", not 0 — an hour with no telemetry is not an idle hour, and a denominator must be what was observed, never the roster.
4. A feature is done only when a test proves it. Status is recorded as works / scaffolded / stubbed, never as a checkbox.

What the wiki covers

Concepts — Glossary · Architecture · Roles and Permissions

Workflow — Customer Workflow · Farm Workflow · Storefront Guide · Console Guide

Lifecycles — Order · Job · Materials · Fleet · Post-production and packing

Money — Pricing · SLA and Variance · Payments

Running it — Installation · Configuration · Deployment · Operations · Backup and Restore · Database Maintenance · Troubleshooting

Building it — Development and Governance · API Reference · Project Status