# step.parts: a searchable catalog of open source STEP parts for CAD assemblies > step.parts is an MIT-licensed Next.js directory of open source STEP models, with a public JSON API and a CLI helper for adding new parts. It is built for engineers who need a fastener, bearing or connector model without modelling it themselves, and it is not a general-purpose 3D model host. **earthtojake/step.parts** — 12,000+ open source STEP parts for your next CAD project - Repository: https://github.com/earthtojake/step.parts - Website: https://www.step.parts - Stars: 362 · Forks: 51 - Language: TypeScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/earthtojake-step-parts ## What step.parts is for, and who it is not for The problem step.parts targets is narrow and real: a CAD assembly needs a socket head cap screw, a bearing, a standoff or a dev board outline, and modelling that part from a datasheet wastes an afternoon. The directory collects open source STEP models for exactly those components and pairs each one with human-authored metadata, so a search for a thread size or a standard number returns a file rather than a shape you still have to measure. The README lists the component families it covers: fasteners and hardware, stock and structural parts such as extrusion profiles and brackets, motion and power transmission parts including bearings, gears and belts, electronics and thermal parts such as connectors, sensors, heatsinks and fans, and actuators and robotics parts including servos and gear reducers. That list also defines the boundary. This is a source of standard and semi-standard geometry, not a place to publish a product you designed. If your part is proprietary, or if it only exists as a parametric model you intend to keep editing, the catalog is the wrong home for it. The README's contribution path assumes a STEP file plus metadata, and STEP is a boundary-representation exchange format, so what you get back is a solid, not a feature tree with named dimensions you can drive. ## How the catalog, the API and the preview pipeline fit together Each catalog entry is described as pairing a canonical STEP file with human-authored metadata and generated preview assets. The repository layout backs that up: there is a catalog/ directory, a scripts/ directory, a src/ directory for the Next.js app, and a public/ directory that holds generated preview files during local work. The README's contribution walkthrough names the artifacts a single part produces: the source entry in catalog/parts.json, the canonical STEP file under catalog/step/, a regenerated SQLite catalog at catalog/parts.sqlite, and exported GLB and PNG previews. So the catalog is not a folder of loose files. It is a JSON source of truth, a SQLite build product, and a media set, all kept in step by scripts. The public API lives under https://api.step.parts/v1, and the README notes the app uses the same /v1 routes locally for server-side search, filtering, downloads and pagination. That is a sensible arrangement: the website and any external client hit the same query surface. The README gives these lookups: https://api.step.parts/v1/parts?pageSize=100 https://api.step.parts/v1/parts?q=M3&tag=screw&page=2 https://api.step.parts/v1/parts?category=fastener&family=socket-head-cap-screw&standard=ISO%204762 https://api.step.parts/v1/parts?q=lengthMm%2012 Machine-readable descriptions are published alongside it at https://api.step.parts/v1/openapi.json, https://api.step.parts/v1/catalog/schema and https://api.step.parts/v1/catalog/parts.index.json. The OpenAPI document is the piece worth reading first, because it tells you the exact query parameters and response shape without you having to infer them from the four examples above. Preview assets are served from Vercel Blob in production, per the README badges and the commented keys in .env.example. ## Installing step.parts locally and adding your first part The README requires Node.js 22.5 or newer, and package.json enforces this with an engines field of >=22.5.0. A .nvmrc file is included, so nvm use selects the same major version CI uses. Clone the repository, then install and start the dev server: ```bash nvm use npm install npm run dev ``` The README says to open http://localhost:3000. That runs the directory UI against the local catalog, and the same /v1 API routes are used server-side, so search and filtering work without any external service. Adding a part goes through the helper script rather than by hand. The README states that the command prompts for a local STEP file path, part metadata, tags, aliases, optional standard details and attributes, then generates the part id, copies the STEP file into the catalog, updates the source catalog, refreshes SQLite catalog metadata, exports GLB and PNG previews, and validates everything: ```bash npm run catalog:add ``` If you would rather see the generated record before anything is written, the README gives a dry-run form that takes the values as flags. Note the -- separator before the options: ```bash npm run catalog:add -- --dry-run --step /path/to/part.step --name "Example part" --category fastener --family socket-head-cap-screw --tag screw --attr thread=M3 ``` Before opening a pull request, the README asks you to review the new source entry in catalog/parts.json, the canonical STEP file in catalog/step/, the regenerated catalog/parts.sqlite, and the generated preview URLs. It also states that local public/glb/ and public/png/ files should not be committed. Then run the checks: ```bash npm run catalog:check npm run lint npx tsc --noEmit ``` The README points to TAGGING.md for tag conventions and DEVELOPMENT.md for the catalog schema, asset generation and deployment details. Contributions go through pull requests against a branch, not direct pushes to main. ## The SQLite build step and the Blob dependency are the friction points Two parts of the pipeline carry real cost. The first is that the catalog is a build artifact. Editing catalog/parts.json is not enough; the SQLite file has to be regenerated, and the check scripts exist to catch a catalog that has drifted out of sync. That is the right design for a directory of this size, but it means a local checkout is only as good as the last catalog build, and a contributor who edits JSON and skips npm run catalog:check will find out in CI rather than in the editor. The second is preview generation. Exported GLB and PNG assets are served from Vercel Blob in production, and .env.example states that BLOB_READ_WRITE_TOKEN is required by npm run catalog:sync-assets and npm run catalog:check:published, while STEP_PARTS_BLOB_BASE_URL is required in production to build GLB and PNG URLs. In local development, generated public/glb and public/png files are used first, and missing local previews fall back to the public step.parts Blob origin by default. So a fresh clone renders previews by reaching out to the project's own storage. That is convenient, and it also means preview generation is not fully self-contained: without a Blob token you cannot run the published-asset check, and you cannot regenerate the shared preview set. The .env.example file also exposes STEP_PARTS_STEP_ASSET_MODE=local, described as forcing checked-out STEP files instead of GitHub LFS media in a production-like local run. That comment is the clearest signal that STEP media normally comes from GitHub LFS rather than from the working tree, which matters if you are trying to run the whole thing offline. The README does not document a rollback path for a catalog change that has already been published to Blob. ## Licensing: MIT covers the project, not every STEP file The repository is MIT-licensed, and the README is explicit that this applies to original project material. It then states that some STEP/model files are copied from, modified from, adapted from, or generated using clearly licensed third-party model sources, and that the MIT License does not relicense third-party-derived STEP/model files. THIRD_PARTY_NOTICES.md is named as the place holding source, attribution, modification and license details. This is the single most important operational fact about the catalog, and it cuts against the convenience the directory offers. A catalog entry is not automatically safe to drop into a commercial assembly just because the surrounding repository is MIT. Each third-party-derived file carries its own terms, and the README directs you to the notices file for them. The practical consequence for a build pipeline is that the MIT licence on the code and the licence on the geometry are two separate questions, and only the first is settled by the repository's LICENSE file. Nothing in the README describes an automated per-file licence filter in the API response, so checking provenance is a manual step against THIRD_PARTY_NOTICES.md. This is not legal advice; it is a description of what the repository says about its own files. ## How step.parts differs from GrabCAD and from a parts library inside your CAD tool The obvious alternative is a general model-sharing site such as GrabCAD, and the difference is in what the metadata is for. On a general sharing site, a model is uploaded with a title, a description and whatever tags the uploader chose, and search quality depends on that free text. step.parts instead treats metadata as a schema: the API accepts category, family, standard and tag as separate query parameters, and the README's example filters on category=fastener, family=socket-head-cap-screw and standard=ISO 4762 in one request. That structure is what makes a query like q=lengthMm%2012 possible at all, because the length is an attribute rather than a word in a description. The second alternative is the built-in parts library that ships with commercial CAD tools. Those libraries are parametric: you insert a screw and pick a length, and the feature tree updates. step.parts returns a STEP file, which is a fixed solid. For a one-off assembly that is fine and often faster, because you skip the library's configuration UI. If your design needs the fastener to change size as the assembly changes, the parametric library wins, and no amount of catalog metadata changes that. A third difference is the API. A sharing site gives you a web page and a download button; step.parts publishes an OpenAPI document and a parts index at predictable URLs. If you are generating assemblies from a script or feeding a bill of materials, that is the difference between a manual download and a fetch. ## Maintenance status and what an upgrade actually costs The repository is not archived, and the last push was on 2026-06-13. There are no releases, and package.json carries version 0.1.0 with a private flag, so this is an application repository rather than a published package. There is no npm install step for consumers and no version to pin against; you consume the hosted API or you fork the app. That shapes the upgrade cost in a way that is easy to miss. Because the API is versioned in the path (/v1) but the repository publishes no releases, the practical contract is the OpenAPI document at https://api.step.parts/v1/openapi.json rather than a changelog. If you build against the API, that document is what you should diff when you notice behaviour changing, because the README gives no deprecation policy. For the app itself, the dependency set is modern and therefore moves: the README badges list Next.js 16.2.6, React 19.2.4 and TypeScript 5.x, and package.json pins next at 16.2.6 and react at 19.2.4. A fork that sits for a year will face a major-version upgrade in both Next.js and React before it faces anything else. The catalog side ages better, since a STEP file for an M3 socket head cap screw does not go stale, but the scripts that validate and export it are tied to the same Node 22.5 floor as the app. ## Conclusion Adopt step.parts if you need standard mechanical and electronics geometry that already carries metadata, and you are willing to check each part's provenance in THIRD_PARTY_NOTICES.md before it goes into a shipped design. Skip it if you need a parametric feature tree you can edit, or if you want a hosted assembly tool rather than a file source. Before relying on any single part, open its catalog entry, confirm the STEP file resolves, and read the third-party notice for that entry. The MIT licence covers the repository's own material only, and the catalog's third-party-derived STEP files keep their original terms. ## FAQ ### What kinds of parts does step.parts include? The README lists fasteners and hardware, stock and structural parts such as extrusion profiles and brackets, motion and power transmission parts including bearings, gears, pulleys and belts, electronics and thermal parts such as connectors, sensors, heatsinks and fans, and actuators and robotics parts including servos, motors and gear reducers. ### Does step.parts have an API I can query programmatically? Yes. The public API lives under https://api.step.parts/v1, and the README gives lookups such as https://api.step.parts/v1/parts?q=M3&tag=screw&page=2. Machine-readable documentation is published at https://api.step.parts/v1/openapi.json, along with a catalog schema and a parts index. ### How do I add a part to the step.parts catalog? Contributions go through pull requests, and the README points to the add-part helper, npm run catalog:add, which prompts for a local STEP file path, metadata, tags and attributes, then copies the file, updates the catalog, refreshes the SQLite metadata, exports GLB and PNG previews and validates the result. Before opening the PR you review catalog/parts.json, the STEP file in catalog/step/ and the regenerated catalog/parts.sqlite, then run npm run catalog:check, npm run lint and npx tsc --noEmit. ### What Node.js version does step.parts require? The README says to use Node.js 22.5 or newer, and package.json enforces this with an engines field of >=22.5.0. The repository includes a .nvmrc file so that nvm use selects the same major version used by CI. ### Is every STEP file in step.parts covered by the MIT licence? No. The README states that the repository is MIT-licensed for original project material, and that the MIT License does not relicense third-party-derived STEP/model files, which are copied from, modified from, adapted from or generated using third-party model sources. THIRD_PARTY_NOTICES.md holds the source, attribution, modification and license details. ## Sources - [earthtojake/step.parts on GitHub](https://github.com/earthtojake/step.parts) - [Issues](https://github.com/earthtojake/step.parts/issues) - [License: MIT](https://github.com/earthtojake/step.parts/blob/main/LICENSE) - [Project website](https://www.step.parts) - [README](https://github.com/earthtojake/step.parts/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/earthtojake-step-parts