FluidCAD makes the model file a JavaScript file you can diff

The model is a JavaScript file, not a binary document

FluidCAD is described as parametric CAD in JavaScript, with the summary line making the point that you model with the mouse or write code and both edit the same file. That single design decision is the project. A part is a JavaScript file you can inspect, edit and version with Git, and the parametric relationships are expressed as named parameters rather than as values typed into a dialog. A file such as `plate.part.js` holds the whole design, and changing the Thickness or Hole diameter in the Parameters panel resizes the part because the geometry was written in terms of those parameters. The project also has a live 3D workspace, a sketch solver and an assembly system, so this is not a code-only modeler with a text editor attached. The topics attached to the repository mention 3D printing and mechanical engineering, and the keyword list in the manifest includes opencascade.js, brep, step and stl, which places the geometry kernel underneath the JavaScript layer.

The sketch solver keeps relationships while you drag

The feature set is a conventional solid modelling one, which is what makes the project interesting rather than a toy. From a profile you can extrude it, revolve it around an axis, or sweep it along a path, then refine the result with cuts, fillets, chamfers, shells and booleans, and repeat features in linear, circular or mirror patterns. The toolbar creates features and the application writes the code, and double-clicking a feature in the timeline opens it for editing, so the history is a code history. The sketch side is where the interesting engineering sits. Dimensions and constraints capture design intent, keeping holes concentric, sides parallel, or an arc tangent to a line, and the solver maintains those relationships as you drag, while snapping adds constraints as you draw. The example in the documentation shows two circles with diameters of 60 and 30 millimetres joined by upper and lower tangent lines, carrying dimensions, constraint badges and a fully constrained status.

A complete part in about twenty lines

The README shows a full mounting plate, and it is short enough to serve as the orientation for the whole API. The imports come from two entry points, `fluidcad/core` for the modelling functions and `fluidcad/shapes` for the shape primitives. A part is created with `part`, parameters are declared with `param` and given a label and a value, a sketch is opened on a plane, and features are applied:

import { part, param, sketch, extrude, circle, cut } from 'fluidcad/core';
import { rect } from 'fluidcad/shapes';

export const plate = part('Mounting plate', () => {
  const thickness = param('Thickness', 6);
  const holeDiameter = param('Hole diameter', 5);

  // Sketch the outline, then give it thickness.
  sketch('xy', () => {
    rect([0, 0], 80, 40).centered();
  });
  const body = extrude(thickness);

The second half of the file sketches on the top face of the solid, which is where `body.endFaces()` comes in, so the holes stay attached to that face when the part is resized, and then cuts through with `cut(thickness)`. Dimensions use the project's units, millimetres by default, and assemblies can override the parameters per instance. The pattern to copy is: declare intent as named parameters, build the shape from them, and let the file be the source of truth.

Assemblies are JavaScript files with mates and joints

Parts compose into assemblies the same way, with a file extension of `.assembly.js`. Mates connect the parts, and the joints are the interesting part: a hinge with a revolute joint, a carriage with a slider, or a mechanism with several linked parts. You drag the assembly to explore the motion it allows, set joint limits, or animate it from the Joints panel. Sub-assemblies can be reused and replicated across a design, which the documentation illustrates with the piston assemblies in a four-cylinder engine model. So the parametric story extends one level up: a parameter in a part can be overridden by an instance in an assembly, which is the behaviour you need when the same bracket is used in two different builds. The exports cover interoperability in both directions, importing existing STEP models with their colours, exporting STEP to other CAD tools, exporting STL for 3D printing, and a PNG export, with assembly STEP exports preserving the part tree.

Three ways to install: the desktop build, npm, or a container

The download table covers the desktop builds, one per platform, with a warning that matters on Windows: builds are not yet code-signed, so SmartScreen appears and the documentation tells you to choose More info and Run anyway. Windows x64 ships as an `.exe` installer, Linux x64 as an `.AppImage` or a `.deb` installed with `sudo apt install ./FluidCAD-*.deb`, and macOS on Apple Silicon as a `.dmg` or `.zip` dragged into Applications. For people who prefer the terminal, the package is on npm and the start screen opens in the browser from any folder:

mkdir my-model && cd my-model
npm init -y
npm install fluidcad
npx fluidcad init
npx fluidcad serve

That creates a project with an empty part, `part1.part.js`, and opens the workspace in the browser, where both the desktop app and the browser workspace include a code editor and a live 3D viewport. A single `npx fluidcad` in any directory opens the start screen with each project in a tab of its own. The container route is the third option, for keeping projects on a server, using the published image or a local build from a clone.

The container listens on 3100 and proxies each project engine

The compose example in the documentation is short, and the variables in it are worth reading carefully before you expose it:

services:
  fluidcad:
    image: ghcr.io/fluid-cad/fluidcad:latest
    ports:
      - "3100:3100"
    environment:
      FLUIDCAD_NO_AUTH: "1"

The environment variable disables authentication, and the documentation frames that as appropriate for a network you trust, such as a home LAN or Tailscale, with no sign-in. That is a security decision for the operator, not a default to accept blindly on a public network. The Dockerfile in the repository shows the rest. It builds on node:24-bookworm-slim, runs `npm ci` against a cached lockfile layer, then builds the package, packs it with `npm pack`, prunes to production dependencies and copies the result into `/app/node_modules/fluidcad` in the runtime image, so that a project's `import 'fluidcad'` resolves. The runtime image exposes port 3100 and starts the launcher with `--host 0.0.0.0 --port 3100 --no-open`, and the comments explain that the start screen listens beyond loopback and proxies each project's engine, which stays on loopback, with its login URL and token printed to the logs. Extra flags such as `--public-url` can be appended.

MIT licensed, pre-1.0, and not accepting pull requests

The licence is MIT, and the manifest records the author as Marwan Aouida, with the package published as `fluidcad` at version 0.0.47. The release list shows a rapid pre-1.0 cadence, v0.0.45 on 2026-09-25, v0.0.46 on 2026-10-05 and v0.0.47 on 2026-10-16, with the last push to the repository on 2026-10-19 and the repository not archived. Two statements in the documentation set the expectations. Pull requests are not being accepted yet while the design and roadmap take shape, with community contributions planned for v0.1.0, and the project is under active development with APIs and features that may change. The exported module paths show how much surface is in flux, with separate entry points for core, filters, constraints, shapes, server, server/api, math, units, browser and viewer-ui, and the repository also carries `mcp/` and `llm-docs/` directories, plus PRODUCT.md and BRANDING.md. For an adopter, the practical consequence is to pin a version and expect to rework call sites when the 0.1.x line lands.

Editorial conclusion

Engineers who want a parametric model under version control, who are comfortable reading a JavaScript file that describes a mechanical part, and who want to automate a pattern or a parameter sweep will find the code-first approach genuinely different from a feature tree in a desktop CAD package. It is the wrong tool for a team that needs a stable, documented API surface today, because the project is pre-1.0 and says so, and it is the wrong tool for anyone who needs signed Windows binaries, since the installers are not yet code-signed. Before adopting it, run `npx fluidcad init` on a scratch folder, open the generated `part1.part.js`, and check the version of the `fluidcad` package you are pinning against the release list.

Frequently asked questions

Official sources

1. Fluid-CAD/FluidCAD on GitHub
2. License: MIT
3. Project website
4. README
5. Releases