# LaserWeb4: a browser front end for GRBL, Smoothieware and TinyG boards > LaserWeb4 is a JavaScript and webpack front end for sending GCODE to laser and CNC controller boards from a browser, with a Docker path that passes a serial device through to the container. It is a development environment first, and its release history has not moved since 2018. **LaserWeb/LaserWeb4** — Collaborative effort on the next version of LaserWeb / CNCWeb - Repository: https://github.com/LaserWeb/LaserWeb4 - Stars: 807 · Forks: 218 - Language: JavaScript - License: AGPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/laserweb-laserweb4 ## A browser front end for the controller board you already own LaserWeb4 exists to remove the vendor software requirement from laser and CNC controllers. The project page describes itself as a collaborative effort on the next version of LaserWeb and CNCWeb, and the topic tags name the controller world it targets: gcode, grbl, smoothieware, tinyg, cnc-controller and laser. The audience is therefore people who already own a GRBL, Smoothieware or TinyG board and are tired of the vendor utility that came with it, plus hobbyists who would rather cut shapes from a browser tab than from a bundled desktop program. There is an important caveat stated up front: the repository is described as a development environment, and the page says no regular user would have to touch it, with binaries published separately under LaserWeb4-Binaries. That shapes how you should read everything else here. ## webpack-dev-server next to a separate communication server The project is written in JavaScript and packaged with webpack, Babel and jsdoc. The package manifest sets the entry point to ./src/index.js and defines a set of npm scripts that show how the pieces fit together. Two of them run at once: one starts the webpack dev server, the other starts a separate communication server from the lw.comm-server module, and a third script runs both in parallel so the interface and the serial bridge come up together. There is also a production bundle script, a docs script that runs jsdoc against the jsdoc.json configuration, and a golive script that checks out the gh-pages branch, merges dev-es6 into it, regenerates the dist folder and pushes it. The repository root holds a dist directory, a .babelrc, a webpack.config.js and a .env file, and a .gitmodules entry means lw.comm-server arrives as a git submodule. Note the default branch is dev-es6, not master. ## Docker with the serial device passed straight through The shortest path to a running instance is the published image, which is documented with a single command that maps the machine's serial device and the web port: ```sh docker run -device=/dev/ttyUSB0 -p 8000:8000 joesantos/laserweb:latest ``` After it starts you open http://localhost:8000 to reach the interface. The Dockerfile in the repository root shows how the container is assembled: a base stage on node:10-alpine that copies package*.json and the sources, a dependencies stage that installs build tooling with apk including make, gcc, g++, python, python3, linux-headers, udev and git, and then runs npm ci. It also rewrites git URLs so that github.com is fetched over https instead of ssh, which matters when the submodule dependency is fetched during the image build. A separate test stage runs the test script, and the dev stage installs nodemon and copies the production node_modules over. The base stage exposes port 8000, matching the port mapping in the run command. ## Building the dev target and the release target from the Dockerfile Two build targets are documented, and they exist for different reasons. The dev target is what a contributor runs, and it is invoked with an explicit target flag: ```sh docker build --target dev -t laserweb:dev . ``` Running the resulting image keeps the container attached so you can work inside it: ```sh docker run -it -device=/dev/ttyUSB0 --rm -p 8000:8000 laserweb:dev ``` The release image is built from a separate Dockerfile with the release suffix: ```sh docker build -f Dockerfile.release -t laserweb:release . ``` The application is then reached on http://localhost:8000 in the same way as the published image. One practical detail deserves attention in any of these commands: the device flag is written with a single dash, exactly as the project page shows it, and the serial path /dev/ttyUSB0 is the example. On a host where the board enumerates as a different node, or where a udev rule renames it, the mapping has to follow the host device rather than the example. ## Firmware support is uneven and the table admits it The support matrix is the most useful document in the repository, and its candour is unusual. Grbl above version 1.1f on ATmega328, Grbl-Mega on ATmega2560, Grbl-LPC on LPC176x and Grbl_ESP32 on ESP32 are all listed as supported with good raster performance and great CNC support. Smoothieware is marked as supported with an asterisk, but rated okayish on both raster performance and CNC support, and the page says that for fast raster engraving it suggests replacing Smoothieware with grbl-LPC, which runs on LPC1769 based boards and performs much faster for laser raster work. TinyG gets good CNC support with raster performance listed as unknown, and RepRapFirmware is marked as supported for CNC. Marlin, MarlinKimbra and Repetier are listed as supported but with no CNC support at all and raster performance marked unknown. The page notes the firmware list is ever changing and points to the issue tracker for details. The alternative here lives at the firmware level rather than in another browser front end, and that is the difference that matters: grbl-LPC keeps the same GRBL command set on a faster LPC1769 class board, so the LaserWeb layer stays the same while the motion performance changes. ## The GCODE optimiser and TSP raster are still wishlist entries The wishlist section is a fair indicator of what the project cannot yet do. It asks for a GCODE optimiser that cuts down on G0 moves, with a genetic algorithm travelling salesman problem approach cited as an example of the kind of tool wanted, and it asks for a Raster to TSP-Vector operation. Both are unimplemented. The wishlist also lists more controller firmware, WebGL transformation filters for using a webcam to set up stock, and automated Electron builds for all platforms. The project page frames these as long standing community requests that the maintainers lack either the time or the extra skills to code. For an engineer, that tells you the toolchain will not shorten your toolpath and will not convert a raster engraving into a vector path on its own, so job preparation still needs another program. ## AGPL-3.0 on a project whose last release tag is from 2018 Two facts should shape your adoption decision. The licence is AGPL-3.0, with the text stored in LICENSE.md, and the project hosts a companion service in the same stack, so a hosted deployment of the server side carries the copyleft obligation further than a plain permissive licence would. Read LICENSE.md before you wrap this in a product. The second fact is chronology. The repository is not archived and the last push was on 2026-04-23, yet the newest published release is v4.0.996 dated 2018-06-29, with v4.0.994 and v4.0.993 from the weeks before it. The version string in the package manifest reads 4.0.999, ahead of the newest tag. Support for a given firmware is therefore also a moving target, and the page routes questions to the community forum while asking that only confirmed bugs be filed on the issues tab. ## Conclusion LaserWeb4 suits hobbyists and small shops that want a browser instead of a vendor controller app, and it suits contributors who want to extend a firmware integration rather than build a front end from scratch. It does not suit production equipment that needs a current, versioned release, since the newest published tag is v4.0.996 from 2018-06-29. Before adopting it, confirm your controller firmware appears in the support table with the performance you need, read LICENSE.md for the AGPL-3.0 obligations on a hosted service, and test the Docker serial pass-through with your actual /dev device node before building tooling around it. ## FAQ ### How do I run LaserWeb4 in Docker and reach its interface? The project page gives the command docker run -device=/dev/ttyUSB0 -p 8000:8000 joesantos/laserweb:latest, and you then connect to http://localhost:8000. For development you can instead build the dev target with docker build --target dev -t laserweb:dev . and run that image the same way. ### Which controller firmware does LaserWeb4 support for fast laser rastering? The support table rates Grbl-LPC on LPC176x and Grbl_ESP32 on ESP32 as great for raster performance, with Grbl and Grbl-Mega rated good. Smoothieware is rated only okayish for raster performance, and the page suggests replacing Smoothieware with grbl-LPC for fast raster engraving. ### Is LaserWeb4 still maintained, and what version should I expect? The repository is not archived and the last push was on 2026-04-23, but the newest GitHub release is v4.0.996 from 2018-06-29. The package manifest version reads 4.0.999, and the default branch is dev-es6 rather than a release branch. ### Can LaserWeb4 do CNC milling as well as laser work? CNC support is listed as great for the Grbl family including Grbl-LPC and Grbl_ESP32, good for TinyG and RepRapFirmware, okayish for Smoothieware, and no for Marlin, MarlinKimbra and Repetier. Check the firmware row that matches your board before planning a workflow. ## Sources - [Issues](https://github.com/LaserWeb/LaserWeb4/issues) - [LaserWeb/LaserWeb4 on GitHub](https://github.com/LaserWeb/LaserWeb4) - [License: AGPL-3.0](https://github.com/LaserWeb/LaserWeb4/blob/dev-es6/LICENSE) - [README](https://github.com/LaserWeb/LaserWeb4/blob/dev-es6/README.md) - [Releases](https://github.com/LaserWeb/LaserWeb4/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/laserweb-laserweb4