Manyfold: a self-hosted Rails asset manager for 3D print files
A self-hosted digital asset manager for 3d print files.
At a glance
- What is it?
- Manyfold is an AGPL-3.0 Ruby on Rails application that catalogues 3D models, stores and renders them in the browser with THREE.js, and runs background analysis through Sidekiq. It suits people with a growing STL and OBJ collection; it is not a slicer, and the README leaves deployment guidance to the project's own site.
- Who is it for?
- Adopt Manyfold if you already run a self-hosted stack, want your STL and OBJ files catalogued on your own hardware, and can support Rails 3.4-era tooling plus PostgreSQL. Do not adopt it if you need a slicer, a single static binary, or a hosted service with an SLA.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Ruby, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Manyfold fills between a downloads folder and a slicer
A 3D printing collection tends to start as a flat directory of STL and OBJ files with names like part_final_v3.stl. Slicers open one model at a time and keep no library. Cloud model repositories hold someone else's catalogue, not yours. Manyfold targets that middle ground: the README describes it as an open source, self-hosted web application for managing a collection of 3d models, particularly focused on 3d printing. The intended user is someone who already self-hosts services, has accumulated print files, and wants them indexed, previewed and searchable from a browser on their own machine. The repository topics confirm the scope: digital-asset-management, stl, obj-files, self-hosted. It is not aimed at people who print occasionally from a single vendor's file library, and it is not a print preparation tool.
Rails, Sidekiq and two 3D engines: the architecture in the repository
The README states the application is built in Ruby on Rails and tries to follow that framework's best practices. It also states Manyfold is a server-side app that uses plain old HTTP requests, with no code using XHR, Websockets or other more interactive comms yet, though that could change. That is a notable design constraint: pages are rendered on the server, and the interactive 3D preview is a client-side layer rather than a single-page application. The stack splits into an application server plus a background job runner using Sidekiq for asynchronous tasks. PostgreSQL is the production database, while sqlite3 is used in development. On the rendering side there are two separate engines: THREE.js via TypeScript for client-side 3D rendering, and Mittsu, described in the README as a Ruby port of THREE.js, for server-side 3D code. That duplication is deliberate. The browser draws the model you are looking at; the server can process geometry without a browser, which is what makes thumbnail and analysis jobs possible in the background queue. Bootstrap 5 supplies the frontend CSS and JS.
Running it locally: bin/dev, corepack, and the Procfile
The README gives a concrete local setup path. Prerequisites are Ruby 3.4, Bundler 2.6 or later, Node.js 24.18.1 with corepack enable run, Yarn 3.8 or later, Foreman or another Procfile runner, libarchive for upload support, imagemagick for image thumbnail generation, ngrok for ActivityPub development, and assimp for model file analysis. Once the repository is cloned, the README says you should be able to just run bin/dev, which sets up the database, performs migrations, installs dependencies, and makes the application available at http://127.0.0.1:3214. Optional features are configured through environment variables placed in a file called .env.development.local, with env.example as a template. The README notes that the required environment variables listed in the documentation are not needed in development mode because of the SQLite substitution for PostgreSQL. One wrinkle: bin/dev also expects to start a pre-configured ngrok tunnel named manyfold so that ActivityPub federation works in development. If you do not want that, the README says to remove the line from Procfile.dev and asks that you do not commit the change. The ngrok config block in the README maps the endpoint name manyfold to upstream url 3214, matching the local port. A devcontainer configuration is also provided for Visual Studio Code's Remote - Containers extension, which avoids installing the native dependencies by hand.
Where the documented path stops and your own judgement starts
The README is a developer document. It explains how to run Manyfold from source, not how to deploy it in production, and it points to manyfold.app for installation instructions and user and administration guides. That matters for anyone evaluating the project: the environment variables referenced for optional features live in a configuration page on that site, and the README only tells you that env.example is the template. The production database is PostgreSQL, so a SQLite-backed development instance does not exercise the same storage path. Sidekiq means a second process to supervise, which is a normal Rails deployment shape but an extra moving part compared with single-binary tools. The native dependency list is also real: libarchive, imagemagick and assimp are separate packages that must be present for uploads, thumbnails and model analysis respectively. If assimp is missing, the analysis features that depend on it will not have their input. None of this is hidden, but none of it is spelled out as a deployment checklist in the README either.
ActivityPub in a print library, and the ngrok dependency it creates
The presence of ActivityPub is the least obvious part of the stack. The README lists ngrok as a prerequisite specifically for ActivityPub development and describes the tunnel as enabling ActivityPub federation in development. Federation implies that a Manyfold instance can expose or exchange collection data with other instances on the Fediverse, and the project maintains a social media presence there. The README does not describe the federation model, what is shared, or how access is controlled, so the practical scope of this feature cannot be judged from the supplied material. What can be said is that it shapes the development workflow: bin/dev starts a tunnel, and the Procfile carries a line for it. For a self-hosted print library, that is an unusual coupling. Anyone who wants a purely local catalogue has to edit Procfile.dev, and the README's instruction not to commit that edit means the change is a local patch you maintain rather than an upstream option.
Testing, linting and the cost of tracking a fast release cadence
The repository ships a full quality toolchain. Rubocop with StandardRB rules and extra rulesets for libraries and frameworks checks Ruby, run with bundle exec rubocop. ERB and TypeScript have their own linters, run with bundle exec erb_lint --lint-all and yarn run lint. The test suite runs as a one-off with bundle exec rake or continuously with bundle exec guard, and the README notes that generation of documentation screenshots is done with system specs and is not run by default unless DOC_SCREENSHOT=true is set before bundle exec rspec. Husky can wire linting into a pre-commit hook. The release history shows three versions in roughly five weeks, v0.147.2, v0.148.0 and v0.149.0, all in the 0.x line. That cadence is good for fixes and bad for operators: a self-hosted instance tracking main or the latest tag should expect to run migrations regularly, and the version numbers tell you the project has not declared a 1.0 stability contract. Budget for reading release notes before each upgrade rather than assuming patch-level safety.
AGPL-3.0 and what it means for a private instance
Manyfold is licensed AGPL-3.0. For an individual running an instance at home to catalogue their own STL files, the licence is unlikely to create obligations beyond keeping the source available if they convey the software. The AGPL's network clause becomes relevant when a modified version is offered to users over a network, which is a scenario a self-hosted personal library does not normally reach. This is a description of the licence's general shape, not legal advice, and anyone embedding Manyfold in a commercial service or modifying it for external users should read the full licence text and take their own counsel. The practical point for evaluators is narrower: AGPL-3.0 is a copyleft licence, so it is compatible with the self-hosted use case the project targets and incompatible with closed redistribution that does not release source.
Alternatives and the difference in approach
The obvious comparison is a general digital asset manager such as Immich or a plain file indexer. Those tools are built around photos, video and documents; their metadata models, thumbnail pipelines and viewers assume 2D media. Manyfold's difference is that its rendering and analysis layers understand geometry. It uses THREE.js in the browser and Mittsu on the server, and it depends on assimp for model file analysis, which is what lets it reason about a model rather than just store it. A generic DAM would hold an STL as an opaque attachment with no preview and no geometry-aware processing. The trade is scope: Manyfold will not manage your photos, and a general DAM will not tell you anything about a mesh. If your library is mixed media, you will end up running both, or accepting that your print files live in the weaker of the two.
Editorial conclusion
Adopt Manyfold if you already run a self-hosted stack, want your STL and OBJ files catalogued on your own hardware, and can support Rails 3.4-era tooling plus PostgreSQL. Do not adopt it if you need a slicer, a single static binary, or a hosted service with an SLA. Verify first that the documented environment variables in env.example match the features you intend to switch on, and confirm your PostgreSQL and Sidekiq setup before importing a large library.
Community notes