What makes a print library production grade

“Production grade” usually arrives as a compliment with nothing behind it. It does have a testable meaning, though, and the tests are unkind to most of what runs in a homelab, including some of what I would defend.

Four questions cover it. Can the system tell you when it has lost something? Has its restore path been exercised by you rather than by its author? Does it stop when it is confused instead of guessing? Can it say who changed what? Self-hosted 3D printing tooling tends to be graded on the fourth question, which is the easiest, and to fail the first, which is the one that costs you a library.

Can it tell you when it has lost something

This is the property nobody asks for and everybody needs. A model library is write-once and read-rarely: you import a mesh, you slice it, and then you do not open the original for a year and a half. That is the worst possible access pattern for detecting damage, because the gap between the loss and the discovery is long enough that no backup rotation still holds the good copy.

The test is simple. Ask the tool to verify that the bytes it thinks it has are the bytes on disk, and see whether it can. A library that stores a hash at upload and never checks it again is not doing integrity, it is doing bookkeeping.

PrintStash does have this, and it arrived in v0.11.1 as the vault audit. A run walks the files it owns, compares each one against its recorded size and checksum, and reports a missing blob, a size mismatch, a hash mismatch, or an unreadable object as a critical finding. It also checks the invariants a library can break on its own: a model with no live file, a recommended revision that no longer exists, two revisions both marked as recommended, metadata that failed to parse, a thumbnail that is gone. Findings persist, you can mark one as deliberately ignored, and a narrow set can be repaired in place. Managing a large library covers running it.

What it does not do is inspect your geometry. A mesh that hashes correctly and has always been broken stays broken, and no storage-integrity check has an opinion about non-manifold edges. That distinction gets blurred often enough to be worth stating plainly.

Has the restore been tested, by you

Every project ships a backup feature. Far fewer ship a restore that someone outside the project has run, and the gap between those two is where most data loss actually happens.

The shipped model is worth knowing precisely, because two parts of it are boundaries rather than features. A full backup contains the database, the files PrintStash owns, documents, thumbnails, and a manifest, and it can be mirrored to an S3-compatible bucket. It does not contain the source bytes of anything indexed from a shared volume, because PrintStash does not own those, so a NAS folder mounted in place is covered by your NAS policy and by nothing else. And the built-in database backup supports file-backed SQLite only: a PostgreSQL install needs operator-managed pg_dump, and the backup API reports that capability rather than pretending otherwise.

The parts I would actually defend are narrower and more specific than the feature name. Backup creation fails closed when an owned file is missing, unreadable, or changes size while the archive is being written, so a backup that would have been quietly incomplete does not exist instead. v0.11.3 made the SQLite backup transactionally consistent and the restore staged and rollback-safe. The archive puts its manifest first so listing remote backups does not mean downloading them.

Scheduling and rehearsal are on you. Backups are created on demand, so a cron job or an external caller is the only thing that makes them regular, and a restore you have never performed is a plan rather than a capability. Backups that actually restore walks the recovery path, and it exists because the alternative is finding out during the emergency.

Does it stop when it is confused

If I ranked these four by how much damage their absence causes, this one would come first. A system that guesses when it is uncertain will eventually guess in the direction of deleting something.

The clearest example in the shipped release is the shared-volume scan. A mirrored folder whose mount has dropped looks, to the filesystem, exactly like a folder whose contents were all deleted, and the obvious implementation trashes your entire library in response. PrintStash refuses: a scan aborts without changing the index when the root is missing, unreadable, or empty while the volume still has indexed files, and marks itself errored. Linked external bytes are also excluded from trash hard-delete and storage collection entirely, so the only files it will ever remove from disk are copies it made itself.

v0.11.4 added another one, and it reads as a limitation until you think about what it prevents. One API process per vault is the supported topology, and startup claims a lock and fails fast if another process is already active. Running two replicas against one vault would be the kind of configuration that appears to work for weeks and then interleaves two writers over the same files. Refusing to boot is the better failure.

The same instinct shows up in how the printer providers are described. Moonraker is stable, the other four are beta, and their capability differences are declared per provider rather than averaged into a marketing claim: Bambu LAN has no remote file inventory, Elegoo Centauri has beta upload with no inventory, measured filament use and duration come back from Moonraker only. A tool that reported estimates as measurements would be easier to sell and worse to run a business on. The compatibility matrix is the current version of that table.

Can it say who changed what

The easiest of the four, and the one most projects lead with. PrintStash records audit entries at the persistence layer rather than at the handler, so a create, update, or delete on a tracked row produces a log entry with the actor, the client IP, and a field-level diff of what moved, without depending on someone remembering to add the logging call to a new endpoint. Credential fields are on a redaction list, so API keys, printer access codes, password hashes, and notification channel secrets show as redacted in the diff rather than in the log.

Access control is collection-scoped with View, Edit, and Admin roles, per-printer roles for status, printing, control, and administration arrived in v0.11.1, and OIDC login against Authentik or Authelia landed in v0.11.0 so accounts can live where the rest of your homelab’s accounts live. Setting up a shared library covers how those roles behave with more than one person involved.

Where this is still a hobby project

Being fair about the first four means being blunt about the rest, because a piece that scored itself well on its own criteria would not be worth reading.

There is no high availability and no plan for it. One process, one vault, and a lock that stops you doing otherwise. If the host dies, the service is down until you bring it back, and the recovery time is however long your restore takes.

Notification channel secrets, printer credentials, and other configured secrets are stored unencrypted in the database, like most self-hosted tools of this shape. That is a deliberate tradeoff against a trusted-network assumption, and it is a real one: a database file that leaves your network takes a Telegram bot token and a set of printer access codes with it. What a trusted network means here is the longer version.

Provider coverage still needs hardware. Four of the five providers are beta, and beta in this context means the code paths work against the machines that were available, not against every firmware revision and network setup yours might have. STEP and STP previews were amd64-only when this was written; v0.12.0 added ARM wheels for the tessellation dependency, with CI evidence from an ARM64 image under QEMU rather than from physical Pi hardware.

And the whole category has a validation problem that no amount of internal test coverage fixes. Printer integrations fail in ways that only appear against real hardware over months, and a self-hosted project’s install base is both its test fleet and the population that absorbs the failures.

The part that is not the software’s job

The uncomfortable half of self-hosting something you intend to depend on is that production grade is a property of the operator too, and that half does not ship in a container.

A hosted service does capacity planning, patching, backup verification, and incident response with people whose job that is. Self-hosting moves all of it to you, and the software can only make the job possible rather than unnecessary. An audit nobody runs reports nothing, a backup nobody has restored is just a file on a disk, and an upgrade applied six months late is a known vulnerability with your name on it. Everything above is useful because it makes the operator’s work tractable, not because it removes it.

Which is also the honest answer to whether self-hosted 3D printing infrastructure is production grade. The software can be. Whether your installation is depends on four hours of work per quarter that nobody will remind you to do.

What shipped after this was written

This section described pull request 68 as direction rather than capability, because at the time it was an open branch aimed at v0.12.0. That release published on August 19, 2026, so the work is installable now: durable import jobs that cannot report completion before their outputs are verifiable, Argon2 password hashing that upgrades legacy bcrypt hashes on login, bounded STEP tessellation in a disposable child process, and the change that matters most for the argument above, which is that startup and hourly maintenance no longer infer file ownership by deleting unindexed objects from storage. The v0.12.0 notes cover the rest. The scores earlier in this post describe v0.11.4, which is what they were measured against.

An afternoon’s worth of work

If you want the honest version of this rather than the essay, four things:

1. Run a full vault audit and read the findings, including the ones you decide to ignore.
2. Restore a backup into a throwaway install and open three models in it.
3. Confirm your NAS policy covers the folders PrintStash indexes but does not own.
4. Put backup creation on a schedule, since the API will not do it for you.

None of that is interesting work and all of it is the difference between a library and a folder you hope is fine.

Questions that come up

Is self-hosted 3D printing file management production ready?

For a workshop or small farm, the software side of it is closer than the category’s reputation suggests: integrity verification, transactionally consistent backup with a staged restore, per-collection and per-printer access control, and audit logging have all been in shipped releases since v0.11.4, and v0.12.0 added the storage-ownership fix and durable import outcomes on top. What is not there is high availability, and what is not automatic is the operator’s part, meaning scheduled backups, tested restores, and applied upgrades. If your definition of production ready includes surviving a dead host without you noticing, no self-hosted single-process tool meets it, including this one.

What is the difference between a checksum at upload and real integrity checking?

A hash recorded at upload proves what the bytes were when they arrived. Integrity checking means reading them back later and comparing, which is the only way to catch a failing disk, a bad copy, or an object that a storage backend lost. The distinction matters most for model libraries because the access pattern hides damage for months: you will not open that STL again until you want to reprint it, by which time the good copy has rotated out of your backups. Verification you can run on demand is the difference between finding out on your schedule and finding out on the worst possible day.

Does a self-hosted setup need high availability?

Almost certainly not, and pursuing it is usually the wrong quarter of effort. A print library going offline for two hours costs you two hours of inconvenience, while a print library losing files costs you the files. Spend the effort on recovery time and on verified backups rather than on redundancy, because the failure you will actually experience is a full disk, a botched upgrade, or an unmounted share, and none of those are solved by a second replica. They are solved by the system refusing to act when it is unsure, and by you having a restore you have already practiced.

What should I check before trusting a self-hosted tool with the only copy of something?

Whether it can verify its own storage, what its backup archive excludes, and what it does when it cannot tell what is going on. That third one is the most revealing and the easiest to test: unmount the folder it indexes and run its sync. A tool that reports an error and changes nothing is built by someone who thought about this. A tool that helpfully removes everything it can no longer see has told you what it is. Nine criteria for choosing one covers the rest of the evaluation.

Sources

• PrintStash known limitations for the single-process topology, the SQLite-only built-in backup, and the stored-secret handling.
• PrintStash vault audit findings, audit logging, and external library scanning at the shipped v0.11.4 release in the repository.
• Pull request 68 for the unreleased v0.12.0 work and its own list of remaining release gates. Open and untagged as of August 19, 2026.