Self-host a private Thingiverse-style library

Thingiverse does two jobs at once. It stores files, and it is the place where a few million other people’s models, comments, remixes, and photos live. A library on your own server replaces the first job well and the second one not at all. Anyone who reads a “self-host your own Thingiverse” thread and comes away expecting both is in for a disappointing second day.

The short answer is that you can have the browsing part over your own files, and it looks roughly like you are picturing. What you give up is the catalogue and the people, and neither of those is something you can self-host.

The browsing experience you can reproduce

The server renders a thumbnail from each model’s geometry, so a folder of near-identical filenames stops being a wall of text. Meshes and G-code toolpaths open in a viewer in the browser, which is the fastest way to tell two similar slices apart without launching a slicer. Search covers names, tags, and the slicer settings read out of the files themselves, so “the 0.2mm PETG one” becomes a query instead of an archaeology project.

Collections nest, which matters more than it sounds like it should: a downloaded multi-part project arrives with a directory tree, and you want that tree kept rather than flattened into one bag of files. Tags cut across it. A model record holds a description, the source URL it came from, and its files grouped together, with G-code kept as named revisions of the same model so there is somewhere to write down why the third attempt worked.

That covers most of what people actually do on a public model page, minus the parts below.

The parts a private vault does not do

There is no catalogue. It is the obvious limitation and still the underestimated one, because most of Thingiverse’s value is that somebody else already uploaded the thing you need. Your instance holds what you put in it, so browsing it means browsing your own past decisions. Keep using the public sites to find models: importing from Printables, MakerWorld and Thingiverse covers getting the files back out of them afterwards.

The community layer is missing too. There are no likes or comments, nobody follows your collection, and there is no remix graph or stream of “makes” from strangers who printed your part at 0.28mm and want to tell you how it went. If that is what you were picturing, skip to the Manyfold section before installing anything.

Photos are the limitation that surprises people most. The file types a model can hold in PrintStash 0.11.4 are STL, 3MF, OBJ, STEP, and G-code, all of it geometry. There is no image file type, so you cannot upload three photos of the finished print and hang them on the model page the way a Thingiverse listing does. Each model gets exactly one thumbnail, generated from the geometry or lifted from a thumbnail already embedded in a 3MF or G-code file. Photos and written build notes go in a markdown document inside the collection instead, which does accept embedded PNG, JPEG, GIF, and WebP. That works, and it is a different shape from what you had in mind.

What you get in exchange is narrower and more durable. The files sit on your disk in your own layout, where nobody can take them down or move them behind a login you did not agree to. The metadata is whatever you decided it should be rather than whatever category tree the site imposed on you, and it outlives the platform.

What running it actually involves

Less than the forum thread implied. PrintStash 0.11.4 is a Compose stack of two containers, frontend and api, both pulled as prebuilt images from GHCR for linux/amd64 and linux/arm64, so nothing compiles on the box. Storage defaults to SQLite and local disk in named volumes. Every variable in the Compose file carries a working default, which means there is no .env to write and nothing to edit before the first docker compose up -d.

The one manual step is a setup token. With VAULT_SETUP_TOKEN unset, the API generates one per process and logs it; you read it out of the API log and paste it into the first-run wizard, which creates the first admin account. There is no default username or password. The Compose install walkthrough has the exact commands and the failure modes, and getting started carries on from the wizard through hardware requirements and the first model.

Postgres and an S3-compatible object store ship inside the same Compose file, behind the postgres and s3 profiles, and stay stopped unless you name a profile. Worth knowing, because a first read of that file makes the stack look like five services when two of them start. With the profiles off, port 3000 is the only published port, since the api service is exposed only on the internal Compose network. If the library later outgrows those defaults, SQLite or Postgres, local disk or S3 covers which of the choices you actually need.

You do not have to move your files into it

For anyone with an existing archive, this is usually the deciding detail. A shared volume lets PrintStash index a mounted local or NAS folder in place: it reads the files, mirrors the folder structure as collections, and leaves the source bytes where they are. The Samba share keeps working, the slicer keeps opening the same paths, and removing a model or the whole volume from the library never deletes the originals.

Two things to know before trying it. Shared volumes sit behind a master switch that ships off, so you enable them in settings first. And a mounted root that turns up unexpectedly empty aborts the scan rather than concluding your entire library was deleted, which is the behavior you want the first time a NAS mount fails quietly. Point it at one representative folder before the whole archive; using a NAS with shared volumes covers the mount and the first scan.

Sharing it with one other person

The Thingiverse analogy breaks down here in a way that matters, because “send a link to a friend” and “run a public model site” are separated by a great deal of work.

The built-in option is a share link, and it is deliberately small. You create one per model. It is read-only and unauthenticated, GET requests only, and it expires on a lifetime you pick between 1 and 365 days. Downloading the original file is a separate toggle that stays off unless you turn it on, so you can hand someone a preview without handing over the STL. Only a hash of the token is stored, revoked links return the same 404 as tokens that never existed, and the public endpoints are rate-limited per IP. Revoking one takes a click. What you cannot do is publish a library, because there is no index of shared models and no path for a visitor to walk from one to the next.

The other option is exposing the instance itself through a reverse proxy with TLS, and that one is yours to own: the certificate, the authentication in front of it, the patching, and the consequences. PrintStash has no telemetry and no hosted component, which also means nobody else is watching the door. Reverse proxy and TLS and the trusted-network security model set out what the software assumes about its network, and it assumes more than a public-facing service should.

Neither option turns a private vault into a model-sharing platform, and it is not trying to be one.

If the social part is the point, look at Manyfold

This deserves saying plainly, because it is the one place a competing project answers the question better. Manyfold is a self-hosted model organizer that federates over ActivityPub. Its features page, checked on August 17, 2026, lists federation among the capabilities available now: following models on other instances from inside your own, sharing your models out to Fediverse followers, and likes and comments on the model itself. That is far closer to the Thingiverse social experience than a per-model expiring link. If the sentence you started with was “I want my own Thingiverse that other people can browse and follow”, Manyfold is the honest recommendation.

PrintStash goes the other way on purpose. It is a private library with limited read-only sharing, and it spends its effort on the slicer and printer side: G-code as revisions with recorded outcomes, extracted print settings, and connections to Moonraker, PrusaLink, OctoPrint, Bambu LAN, and supported Elegoo printers. The pairwise comparison works through where each one wins.

A cheap way to find out

Run the two containers on whatever spare machine is lying around, point one shared volume at a single folder of fifty or so models, and use it for a week as your actual way of finding files. The question is not whether the grid looks good on day one. It is whether, a week later, you reach for the browser or open the file manager out of habit. If it is the file manager, the folder tree was already fine and you have talked yourself out of a migration.

Questions that come up

Can I make a self-hosted library public so other people browse it like Thingiverse?

Not with PrintStash. The only outward-facing surface is a per-model share link, and there is no index page for a visitor to browse, so there is no way to walk from one shared model to the next. You can expose the whole instance through a reverse proxy with TLS, but that publishes a private application with logins rather than a public catalogue, and securing it is your responsibility. If a browsable, followable public instance is the goal, Manyfold’s ActivityPub federation is built for it and PrintStash is not.

Do I need a domain name to share a model with someone?

Not inside your own network. A share link is a path on whatever address you already reach the library at, so on a LAN it is an IP and a port, and anyone on that network or on your VPN can open it. A domain and a certificate only start to matter when the recipient is outside the network, because that means publishing the instance through a reverse proxy with TLS and accepting everything that comes with running a public-facing service.

Can I attach photos of the finished print to a model?

Not to the model record. The file types a model holds in 0.11.4 are STL, 3MF, OBJ, STEP, and G-code, and the single thumbnail is generated from the geometry or read out of an embedded 3MF or G-code preview. Photos and written build notes belong in a markdown document inside the collection instead, which accepts embedded PNG, JPEG, GIF, and WebP images. It is a real limitation if you were picturing a listing with a photo carousel.

What happens to my library when the original model page disappears?

Nothing, which is most of the reason to run one. The files are already on your disk and the model record keeps the source URL you imported from, so a deleted listing, a changed license, or a dead account costs you the page and its comments rather than the model. The part worth being honest about is that durability is now your job: a local copy on one disk is a copy, not a backup, and nobody else is running the restore drill for you.

Does a private library mean I stop using Printables and Thingiverse?

No, and planning on that is the usual mistake. Discovery is the thing a public catalogue does that you cannot replicate at home, so keep browsing there. What changes is where the download lands: instead of a downloads folder that goes unsearchable somewhere around the fiftieth model, the file arrives in a library that keeps its source URL, its slices, and its print history, and that still works after the original listing is gone.

Sources

• PrintStash docker-compose.yml, backend/app/db/models.py, backend/app/api/v1/share.py, backend/app/services/share.py, backend/app/api/v1/documents.py, backend/app/services/runtime_config.py, and backend/app/services/external_library.py at tag v0.11.4. Read August 17, 2026.
• Manyfold features, for what its federation covers and which items are listed as available now. Checked August 17, 2026.

For the case against a hosted library rather than the comparison with a public one, read why self-host a 3D printing library. If the archive you want to index is already sitting on a NAS, migrating from folders is the more useful next step.