# grid-apps runs a slicer and a mesh editor entirely in the browser

> The GridSpace grid-apps repository holds Kiri:Moto, a browser based slicer for 3D printers, CNC mills and laser cutters, and Mesh:Tool, a browser mesh editor, both shipped as web apps, Electron binaries and containers. The interesting engineering choice is that the same JavaScript can be driven headlessly through a scripting API, so slicing can run inside a page or a worker.

**GridSpace/grid-apps** — Browser-based Slicer for 3D Printing, CAM, Laser (Kiri:Moto) and mesh editor (Mesh:Tool)

- Repository: https://github.com/GridSpace/grid-apps
- Website: https://grid.space/
- Stars: 930 · Forks: 227
- Language: JavaScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/gridspace-grid-apps

## Two tools in one repository: Kiri:Moto and Mesh:Tool

The repository description is a compact summary of the scope: a browser based Slicer for 3D Printing, CAM and Laser, which is Kiri:Moto, and a mesh editor, which is Mesh:Tool. The README states that Kiri:Moto is a browser based Slicer for 3D printers, CNC mills and laser cutters, and that Mesh:Tool is a browser based mesh repair and editing tool. Both are hosted at grid.space, and the site carries several live versions of the code under a choose page. The package manifest describes the project as grid.space 3d slicing and modeling tools, authored by Stewart Allen, with keywords covering the machine families in scope: FDM, CAM, CNC, mSLA, laser, waterjet, wire edm, dragknife and gcode. The primary language is JavaScript, and the repository mixes app code at the top level with apps/, web/, mods/, src/, conf/ and bin/ directories.

## A web worker that slices, and an IFrame you can drive

The Javascript Slicing APIs are the part that separates this from a web toy. The README describes a script include that injects a web worker into the page, and that worker asynchronously performs any of Kiri's slicing and gcode generation functions. There is also a frame messaging API for controlling Kiri:Moto inside an IFrame. Two live pages are linked for these interfaces, engine.html for the worker include and frame.html for the frame messaging API. The design consequence is worth stating plainly: the slicing engine is not tied to the user interface, so the same code that powers the interactive app can be called from your own page or wrapped in an IFrame for embedding. For a team that wants to put a slicer inside an existing product, that is the feature that matters, and the rest of the repository is the application built on top of it.

## Three local development paths, one setup step

Developers get three documented ways to run the code locally, and they differ only in the last command. The Docker path builds the compose file kept at src/dock/compose.yml:

```bash
git clone git@github.com:GridSpace/grid-apps.git
cd grid-apps
npm run setup
docker-compose -f src/dock/compose.yml up
```

The Electron path replaces the last line with npm run start, and the plain Node path replaces it with npm run dev. The npm run setup step is common to all three, and the repository also documents a documentation build with npm run docs-dev, since the docs are built with Docusaurus and served using GitHub Pages. The package manifest sets an engines field of node >=22.0.0, so the Node path has a hard floor on the runtime. Dependencies are pinned tightly in places, with exact versions for docusaurus plugins and caret ranges elsewhere, and the tree includes the @gridspace/app-server package, the mqtt broker aedes, express-useragent and quickjs-emscripten.

## Containers, TrueNAS and the localhost:8080 entry point

The container path is documented for a specific platform. The TrueNAS section says to use Apps, Discover Apps, Install via YAML, and gives the compose file that builds from the repository at the refs/tags/latest reference with the Dockerfile at ./src/dock/Dockerfile:

```yaml
services:
  kirimoto:
    build:
      context: https://github.com/GridSpace/grid-apps.git#refs/tags/latest
      dockerfile: ./src/dock/Dockerfile
    ports:
      - "8080:8080"
```

For any default install the README says to open a browser to localhost:8080/kiri, so the container publishes a single port and serves the application under a path prefix rather than on separate ports. That is a small detail with a practical effect: behind a reverse proxy you need to route the prefix as well as the port. The same pattern is visible in the package dependencies, which include an aedes MQTT broker and a net-level-client library, so the server side is not only serving static files.

## Electron builds exist, and the install path has hoops

Desktop binaries are published as GitHub releases, and the README points you to the Assets area under the release name to reveal the files. The Linux x86 build needs a fuse package installed and the AppImage made executable, and the README is honest about the friction on the other platforms: the Windows and Mac binaries are not signed, so you will need to jump through a few safety hoops to get them to open the first time. The release history shows regular tagged versions, with 4.7.3 on 2026-08-16, 4.7.2 on 2026-07-27 and 4.7.1 on 2026-06-22, while the package manifest still carries version 4.7.0, which tells you the manifest version and the release tag move on separate cadences. For a user who just wants to slice a model, the hosted version at grid.space needs no install at all, which is the shortest path and the one the project leads with.

## Where a browser slicer stops being the right tool

There are clear boundaries, and the project itself points at two of them. The first is distribution. Unsigned binaries on Windows and Mac are a genuine friction point for a workshop where a technician should not have to click through a security warning on every machine, and the Linux x86 path needs fuse installed. The second is that the code is JavaScript that runs in a browser or in Electron, so anything that depends on native machine access, or on a workflow that expects an installed application with a file association, is outside what this repository delivers. The repository also states plainly that the documentation could really use help, and that the project is a passion project that has consumed most of its author's free time for years. For a commercial workflow where support response time matters, that is a fact about the project rather than a technical limit, but it is the one that decides procurement.

## MIT licence, thirteen years, and a funding request

The licence field on the repository says MIT, and the README states that Kiri:Moto and Mesh:Tool are completely open source and free for use without restriction. That combination, permissive licence with no use restriction, is rare enough to note. The project then says it has been in development for over 13 years, that it has grown well beyond its original scope, and that it has consumed most of the author's free time for many years, with a request for sponsorship through GitHub Sponsors or PayPal. The MIT terms mean a company can embed the slicer in a commercial product without licensing fees, which is the practical answer to the funding gap that the README describes. The last push was on 2026-10-22 and the repository is not archived, so work continues, and the community runs on Discord, a forum at forum.grid.space and a YouTube channel.

## Conclusion

grid-apps suits anyone who needs to slice or repair a mesh without installing a desktop application, and the scripting API makes it a reasonable backend for a service that turns uploads into gcode, since the same code path runs in a worker or an IFrame. It does not suit a shop that needs signed installers, because the documentation states the Windows and Mac binaries are not signed, and it does not suit a machine that cannot run Node 22 or cannot use a container. Before you build from source, clone the repository and run npm run setup, then pick the docker-compose or npm run dev path, and check the AppImage fuse requirement on Linux x86 before you rely on the desktop build.

## FAQ

### What is Kiri:Moto and what can it slice for?

Kiri:Moto is a browser based Slicer for 3D printers, CNC mills and laser cutters. The package keywords also name mSLA, waterjet, wire edm and dragknife as machine families in scope.

### Can I run Kiri:Moto locally without a desktop install?

Yes. The documented Docker path clones the repository, runs npm run setup and then docker-compose -f src/dock/compose.yml up, after which you open a browser to localhost:8080/kiri.

### What does the Kiri:Moto scripting API offer?

A script include that injects a web worker into the page to asynchronously perform Kiri's slicing and gcode generation functions, plus a frame messaging API for controlling Kiri:Moto inside an IFrame.

### Are there desktop versions of Kiri:Moto and Mesh:Tool?

Yes, Electron builds are published as GitHub releases under Assets. The README notes that the Windows and Mac binaries are not signed, and that Linux x86 needs fuse installed and the AppImage made executable.

### What licence does grid-apps use?

The licence field on the repository says MIT, and the README states that Kiri:Moto and Mesh:Tool are completely open source and free for use without restriction.

## Sources

- [GridSpace/grid-apps on GitHub](https://github.com/GridSpace/grid-apps)
- [License: MIT](https://github.com/GridSpace/grid-apps/blob/master/LICENSE)
- [Project website](https://grid.space/)
- [README](https://github.com/GridSpace/grid-apps/blob/master/README.md)
- [Releases](https://github.com/GridSpace/grid-apps/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gridspace-grid-apps