Makerspace print library: roles, logins, audit

A self-hosted print library can carry a makerspace’s entire access-control job when it has five things: an account per member, roles that separate viewing from editing on the library, permissions that bind per printer, optional single sign-on, and a change history that records who did what. PrintStash has all five, running on your own server under the AGPL license. What it leaves out is just as deliberate: membership billing and door access belong to tools like Fabman, and they work fine alongside it.

Most spaces solve printing access with a console tool built around printers or a cloud platform sold by the seat. Both approaches work, and both put the access decisions somewhere other than the files. This page is the checklist behind the claim above: what each requirement means in practice, how PrintStash meets it, which release brought it, and where the limits sit.

What a makerspace needs from access control

A shared shop is a harder access problem than a home lab, and the differences drive the checklist.

Members join and leave every semester or every quarter. A few people should be able to upload, reorganize, and delete; most should only browse and send jobs. Some machines concentrate risk, so the resin station and the loaded Bambu should be limited to members who passed the induction while the Prusa fleet stays open. And when a model vanishes or someone cancels half the queue, the question “who did this” needs a real answer. A shared password fails all four tests at once, because it makes every action anonymous and every departure a lock change.

So the working checklist looks like this:

1. Individual logins, one per member, so actions have owners.
2. Library-level roles that separate viewing, editing, and administering.
3. Permissions per printer, so machine restrictions do not depend on folder tricks.
4. Single sign-on when the space already runs an identity provider.
5. A change history with the actor and origin recorded.

How PrintStash covers the checklist

Every member gets their own account. Multi-user support with per-user administration has existed since 0.3.0, and each account owns its API keys, saved views, and favorites. When a member leaves, you deactivate or delete one account; nobody rotates a shared password and nobody re-configures a workstation under someone else’s name. Per-user API keys also mean the slicing workstation’s automation is attributable to that station, which matters once more than one station exists. The makerspace library setup guide walks the account layout in detail.

Roles live on collections. Each user can be granted view, edit, or admin on each collection independently, and downloads, previews, and thumbnails respect those grants because authenticated asset delivery landed alongside the role model. A workable starting shape is one approved library everyone can view, a member-uploads collection where contributors can edit, and a workshop-critical collection locked down to maintainers.

Each printer carries its own access ladder. Since 0.11.1, a superuser can grant view, print, control, or admin on any printer independently, and the check runs server-side on every REST call and on the live WebSocket stream, so a crafted request gains nothing over the UI. API keys inherit their owner’s printer grants, and printing goes one step further: it also requires edit access to the source model’s collection, which is why a view-only member cannot start jobs on a printer they can merely see. This is the mechanism behind “resin station for trained members only”: grant the printer, not the folder structure.

Single sign-on is optional and generic. Since 0.11.0, PrintStash speaks standard OpenID Connect: it reads the provider’s discovery document, signs members in with authorization code and PKCE, validates the ID token, and provisions accounts on first login. Membership in one group you nominate makes a member an administrator, and local password login keeps working as the fallback when the provider is down. The project targets Authentik and Authelia explicitly, though anything that publishes a discovery endpoint behaves the same. If your space already runs SSO for the laser cutters, the printers join the same flow. The SSO configuration guide covers the settings and the one-bit nature of the group mapping.

Everything that changes data writes an audit row. Creates, updates, soft deletes, restores, and hard deletes are recorded with the acting user and the source IP, captured by database change-tracking hooks rather than sprinkled logging calls, so the trail does not depend on each developer remembering to log. Secret fields, including printer API keys, access codes, password hashes, and storage credentials, are stored in the trail as [redacted].

What the audit log actually records

Each row carries the action, the resource type and id, a before-and-after diff of the changed fields, the actor id, and the source IP. The redaction is worth understanding as an operator, because it was not always there: before 0.8.5, diffs wrote unredacted before-and-after values, which meant printer API keys and password hashes were readable through the audit endpoint. Version 0.8.5 fixed that by field name, migrated away the previously captured rows, and closed the last coverage gap by recording backup and restore events too. One later refinement matters for browser-only usage: since 0.11.4, mutations made through cookie sessions retain their actor properly, so an action taken in the UI is attributed to the person who clicked rather than logged anonymously.

Reading the trail today is a superuser affair: the GET /api/v1/admin/audit endpoint returns rows newest first, filterable by resource type or specific resource id. There is no dedicated dashboard screen for it in the current release and no forwarding to a SIEM, so if your space ships logs to a central system, you would poll that endpoint with a script. Related operational detail: when PrintStash runs behind a reverse proxy, set FORWARDED_ALLOW_IPS so the audit log records member workstations rather than the proxy’s address, per the repository’s docs/known-limitations.md.

Where PrintStash stops

Roles bind at two levels, collections and printers, not per file. If one model genuinely needs to be hidden from most members, it belongs in its own restricted collection; there is no per-file ACL to reach for.

The audit trail is queryable but bare. Between the superuser-only endpoint and the absence of export tooling, treat it as an incident-investigation tool, not a compliance pipeline, unless you are willing to write the small script that drains it. The restraint has a reason: a log nobody reads is a liability, and this trail exists to answer “who did this” after an incident.

PrintStash assumes a trusted network. It is not designed to sit directly on the public internet; put TLS and a hardened reverse proxy in front of it, or keep it VPN-only. The security model post explains that posture and its reasoning.

There is no membership billing, no door access, and no course booking. Fabman and similar membership systems own that problem space, and PrintStash does not try to absorb it.

When you genuinely need SaaS instead

Cloud platforms earn their keep in specific situations, so it is worth naming them instead of pretending the self-hosted route always wins. 3DPrinterOS and SimplyPrint sell managed fleets: dashboards that span locations, vendor-managed uptime, and seats provisioned without touching a server. If your space has no one who wants to hold the pager and no constraint about files living on someone else’s infrastructure, that is a coherent choice, not a failure of judgment.

Fabman solves the parts PrintStash refuses: memberships, billing, and door access hardware. In practice the two categories combine well, with Fabman deciding who may enter the room and PrintStash deciding who may touch which files and machines once inside.

Setup sketch

The whole checklist fits in a short session:

1. Deploy the stack with Docker Compose and finish first-run setup, which creates the initial superuser.
2. Create one account per member, or point OpenID Connect at your identity provider and let accounts provision themselves.
3. Design the collection tree before granting anything: approved library, member uploads, restricted materials.
4. Grant collection roles broadly for view, narrowly for edit.
5. Grant printer roles per machine, reserving print or control on risky machines for trained members.
6. Set a trash retention window you can live with and take one backup, restored somewhere other than production.

Steps 1 and 6 have their own guides; the library setup walkthrough covers the sequence for a typical space, and the installation documentation covers deployment variants.

Questions that come up

Can each member have their own login on a shared 3D print library?

Yes. PrintStash has been multi-user since 0.3.0: an administrator creates one account per member, and each account carries its own API keys, saved views, and favorites. Deactivating one member affects only that member, which is the property a shared password can never give you. Accounts can alternatively provision themselves through OpenID Connect on first sign-in.

Does PrintStash have audit logs?

Yes. Creates, updates, soft deletes, restores, and hard deletes are recorded with the acting user, the source IP, and a before-and-after field diff. Credential-bearing fields are stored redacted, a fix that arrived in 0.8.5 along with a cleanup of previously captured rows. Superusers read the trail through the /api/v1/admin/audit endpoint; there is no dedicated screen or external export in the current release.

Can I limit who uses a specific printer?

Yes. Since 0.11.1 each printer takes its own view, print, control, and admin grants, enforced server-side on every REST request and on the live WebSocket connection. API keys act with their owner’s grants, and starting a print additionally requires edit access to the model’s collection. Restricting the resin station to induced members is exactly this mechanism.

Does PrintStash integrate with our existing single sign-on?

Any OpenID Connect provider works, with Authentik and Authelia named by the project as the tested targets. The flow uses discovery, authorization code with PKCE, and validated ID tokens, and one configured group controls administrator status. Local login remains available as a fallback, so an identity-provider outage does not lock the room out of the library.

What does PrintStash not cover for makerspaces?

Membership billing, door access, and course booking are outside its scope entirely; pair a membership system such as Fabman for those. Roles attach to collections and printers rather than individual files, so hiding one model means giving it its own collection. And the audit log is readable but bare: a superuser endpoint with no dashboard screen and no SIEM shipping built in.

Sources

• PrintStash source read at tag v0.12.1 (commit afbe54dd430d, checkout hash-verified against the upstream tag), checked August 22, 2026: the audit hook and redaction field list in backend/app/services/audit.py, the role enums and permission tables in backend/app/db/models.py, per-printer enforcement in backend/app/services/printer_rbac.py plus the WebSocket gate in backend/app/api/v1/printers.py, the superuser audit endpoint in backend/app/api/v1/admin.py, and the OIDC service in backend/app/services/oidc.py.
• The repository CHANGELOG.md sections for 0.3.0 (multi-user and collection RBAC), 0.8.5 (audit redaction, backup/restore events), 0.11.0 (OIDC SSO), 0.11.1 (per-printer access control), and 0.11.4 (cookie-session actor retention), read August 22, 2026. Release notes on this blog: v0.8.5, v0.11.0, v0.11.1.
• docs/known-limitations.md in the repository for the trusted-network posture and the FORWARDED_ALLOW_IPS behavior. Checked August 22, 2026.
• Fabman, 3DPrinterOS, and SimplyPrint primary pages, consulted for the categories they serve (membership and access hardware, managed fleet platforms). Status-checked August 22, 2026.