Best Laser Engravers for Linux: GRBL Machines Without LightBurn

The usual advice for picking a laser engraver is “get whatever LightBurn supports”. If you’re shopping for the best laser engraver for Linux, that advice broke in 2025. LightBurn 1.7.08 was the last release with a Linux build, and 2.0 onwards ships for Windows and macOS only, so the default laser software on every forum no longer installs on your Ubuntu or Fedora desktop.

Original content from computingforgeeks.com - post 179414

What still works is the boring part underneath: most open-frame and desktop diode engravers from Creality, Sculpfun, Ortur and Atomstack run GRBL firmware and take plain G-code over USB serial, and Linux senders such as Rayforge, MeerK40t, Universal Gcode Sender and CNCjs speak that protocol. So these notes pick five GRBL machines you can drive from Linux, flag the closed ones to avoid, and show what a GRBL controller actually says to a Linux box. I ran the Linux side in October 2026 on an Ubuntu 26.04.1 LTS VM in my lab against a Grbl 1.1h simulator on a virtual serial port, and every reply below comes from that box.

Picking one in thirty seconds

Which one should you buy? Every machine here either has a GRBL profile in Rayforge, publishes Grbl-derived firmware, or comes from a model line whose owners post GRBL replies. The prices are what Amazon showed me on 29 October 2026, so check the live listing before you order:

• Best overall: Creality Falcon A1 10W, enclosed, about $466
• Best budget: Sculpfun S9 Pro 10W, about $269
• Linux on the spec page: Ortur Laser Master 2 Pro S2, about $350
• Cheapest 20W: Atomstack A20 Pro V2, about $390
• Enclosed 20W: Creality Falcon A1 Pro 20W, about $879

If it is a gift for someone who’ll run it in a spare bedroom, buy an enclosed one. Open-frame diode lasers are Class 4 devices that throw blue light and smoke across the room, and that’s the part a gift card can’t fix later.

Working out what Linux can still drive

A laser engraver runs from Linux when its controller accepts standard GRBL G-code over a serial port. It does not when the vendor wraps the job in its own protocol and only ships its own app. That’s the whole test. The LightBurn change made it matter because LightBurn was how most people hid the difference: it spoke GRBL, Ruida and the xTool protocols, and it ran on Linux until 1.7. LightBurn’s own downgrade guide is blunt about it: “LightBurn version 1.7 is the last version compatible with Linux, versions of Windows prior to 10, and versions of macOS prior to 11.” You can still install the old 1.7.08 AppImage, and a new licence key still activates it, but you would be paying today’s price for a frozen build that will not get fixes or support for newer machines.

LaserGRBL is not an escape hatch either. Its FAQ says it’s “a software for Microsoft Windows OS” and points Linux users at Wine. So I looked at what installs natively on Ubuntu 26.04 and talks GRBL:

Sender	Version (Oct 2026)	Linux install	What I found
Rayforge	1.13.1	Flathub, Snap, PPA, PyPI	Installed and ran on 26.04; ships GRBL profiles for Creality, Sculpfun, Ortur, Atomstack
MeerK40t	0.9.9100	pip, prebuilt binary	Installed; README says maintenance mode; K40 first, GRBL second
Universal Gcode Sender	2.1.27	Linux x64 and ARM tarballs	General CNC sender, works with GRBL and grblHAL
CNCjs	1.11.5	npm, desktop app	Browser UI, handy on a Raspberry Pi next to the laser
LaserWeb4	4.0.996 (last Linux AppImage, 2018)	AppImage	No Linux build since 2018, skip it
LightBurn	2.2.00	None (last Linux build 1.7.08)	Windows and macOS only

Rayforge is the one I’d hand a new owner. It is laser-first, it is on Flathub, and its device list already knows the Falcon A1, A1 Pro, Sculpfun S9 and Ortur’s newer Master 3 and 4. MeerK40t is excellent if you also own a K40 CO2 cutter, but it says itself it’s in maintenance mode, so I wouldn’t build a new workflow on it.

How I tested and picked

I didn’t burn wood with five lasers. No engraver was attached to my lab, so I’m not quoting engraving speeds or cut depths of my own; those numbers are the makers’ and I’ve labelled them that way. What I did test is the half that decides whether a Linux user is stuck: the serial conversation. I built Grbl 1.1h’s simulator on Ubuntu 26.04, exposed it as a virtual serial port, enabled laser mode, streamed a job and collected the error codes a sender has to handle. That’s the same conversation a GRBL board has with Rayforge or UGS over USB.

For the machines, each pick has a manufacturer spec page, a live Amazon listing and a third source (Rayforge’s device profile, the vendor’s firmware repository or owners’ GRBL console logs) behind it. Where a vendor never says GRBL out loud I say so, and I explain why I’m still confident.

Comparing the five Linux laser engravers side by side

Work area and the enclosure are the two columns that should decide it for most people. Do you really need 20W? Only if you plan to cut rather than mark, so power matters less than the marketing suggests:

Model	Optical power	Work area	Enclosed	Connection	GRBL evidence	Price band
Creality Falcon A1	10W	305 x 381 mm	Yes, Class 1, camera	USB (ESP32-S3 native)	Rayforge profile, owner log shows Grbl 1.1f	~$466
Sculpfun S9 Pro	10W	400 x 410 mm	No	USB	Rayforge S9 profile (original 5.5W model)	~$269
Ortur Laser Master 2 Pro S2	10W	400 x 400 mm	No	USB	Grbl-derived firmware, vendor lists Linux	~$350
Atomstack A20 Pro V2	20W	400 x 365 mm	No	USB, Wi-Fi 2.4G	Inferred: A20 Pro owners post GRBL alarms	~$390
Creality Falcon A1 Pro	20W	268 x 358 mm	Yes, Class 1, camera	USB, Wi-Fi	Rayforge profile with Linux notes	~$879

Notice the enclosed machines have the smaller beds. You’re paying for the box, the fume path and the camera, not for more engraving area, so measure the biggest thing you want to engrave before you go enclosed.

Buying the Creality Falcon A1 for a first enclosed laser

The Falcon A1 is the one I’d buy for a home that isn’t a workshop. It’s a 10W diode in a Class 1 enclosure with a camera for positioning, and Rayforge ships a profile for it that drives it as a GRBL serial device at 115200 baud.

Creality’s spec page lists a 305 x 381 mm engraving area, a 455 nm laser, a CoreXY motion system rated at 600 mm/s and “LightBurn, LaserGRBL, Falcon Design Space” as the software. It also lists Windows and macOS as the operating systems, which is the vendor covering itself, not a protocol limit. The controller is an ESP32-S3: an owner’s console log on the LightBurn forum shows [VER:1.1f.20220810:] and [MSG:Using cpu_map…esp32-s3], and Rayforge’s profile lists USB ID 303a:4001. On Linux that native USB port should come up through the in-kernel cdc_acm driver as /dev/ttyACM0 rather than /dev/ttyUSB0. I haven’t plugged one into my own machine, so treat that device name as the expected one, not a capture.

• For: a first laser that lives indoors
• Skip it: if your pieces are wider than about 30 cm
• About $466 (list $549), check the live price

The camera is the part I’m least sure about on Linux. Creality’s Falcon Design Space does the camera alignment, and that app is Windows and macOS only, so plan on Rayforge’s own camera support or jig-and-frame positioning instead.

Starting cheap with the Sculpfun S9 Pro

The Sculpfun S9 Pro is the cheapest machine here that I’d still recommend to someone who wants to keep using it next year. It’s a 10W open-frame engraver with a 400 x 410 mm work area, and Sculpfun publishes one firmware line for the S9 and S30 family. Rayforge’s S9 profile drives that family with its GRBL serial driver, but it describes the original 5.5W S9 with a 410 x 420 mm bed, so set the power and bed size for the Pro yourself.

It connects over USB only, the listing names LaserGRBL and LightBurn as the software, and there’s no air assist in the box. That last one matters more than the power figure: without air the smoke settles back on the cut and your edges char, so budget for an air pump if you plan to cut rather than mark. Its frame also needs a fire-safe surface underneath and a window nearby, because nothing contains the fumes.

• For: the biggest bed per dollar, in a garage
• Skip it: if kids or pets share the room
• About $269, check the live price

I couldn’t capture which GRBL build string the S9 Pro reports, so if you get one, send $I from any sender and you’ll see it in the reply the same way my simulator answered further down.

Trusting Ortur’s own Linux line

Ortur is the only maker in this list whose product page actually names Linux. The Laser Master 2 Pro S2 page says it is “Compatible with Windows from XP to W10 / Linux / Mac OS”. Ortur’s public firmware repositories on GitHub are Grbl derivatives, which is why LaserGRBL and every Linux sender can drive it.

The S2 with the LU2-10A module is a 10W open-frame machine with a 400 x 400 mm area and a quoted top speed of 15,000 mm/min. It’s an older platform than the Creality boxes, and that’s partly why I like it for Linux: there’s years of forum knowledge about its settings, and nobody has to guess at the protocol. Rayforge doesn’t ship a Master 2 profile (it has the Master 3 and 4), so you’d start from its generic GRBL device and set the bed size yourself.

• For: buyers who want Linux in writing
• Skip it: if you want a camera or enclosure
• About $350, check the live price

Ortur sells the same machine cheaper on its own store than on Amazon at the moment, so compare both before you buy. I haven’t confirmed which firmware branch the S2 ships with, only that Ortur’s published firmware is Grbl-based.

Getting cheap 20W from the Atomstack A20 Pro V2

If you need to cut, not just mark, the Atomstack A20 Pro V2 is the cheapest 20W machine I’d consider. Atomstack quotes 20W optical output from a 120W input, a 400 x 365 mm area, 400 mm/s, and both USB and 2.4 GHz Wi-Fi.

So how do I know it speaks GRBL? Honestly, I’m inferring it. Atomstack’s page never prints the word GRBL; it lists “LightBurn, LaserGRBL, Atomstack PC, Atomstack APP”. Owners of the earlier A20 Pro post GRBL alarm codes (ALARM:2, ALARM:9) from it on the LightBurn forum, and the V2 lists the same software, but I haven’t seen a $I reply from a V2. Rayforge has profiles for other Atomstack models but not this one, so you’d use the generic GRBL device over USB. The Wi-Fi side goes through Atomstack’s app, and I wouldn’t count on it from Linux.

• For: cutting on a budget, in a garage
• Skip it: if you want proof of GRBL before buying
• About $390, check the live price

It does have a tip-over alarm, which I’d want on any open 20W frame, because a laser lying on its side doesn’t stop being a laser.

Stepping up to the enclosed Falcon A1 Pro 20W

The Falcon A1 Pro is the A1 with twice the power and the same Class 1 box, and it is the most expensive machine I’d still call Linux-friendly. Creality lists 20W optical output, a 268 x 358 mm area and a 24V 7.5A supply, and an optional 2W infrared module shows on the same page for metal and dark plastics.

Rayforge’s profile for it is the most detailed one I read. It drives the laser over the GRBL serial driver and reaches the camera through a USB network interface the machine exposes, with Linux setup notes in the profile itself. That’s encouraging, because the camera is usually where Linux support falls apart. The bed is smaller than the A1’s, though, so this is a cutting upgrade, not a size upgrade.

• For: indoor cutting with the light contained
• Skip it: if you mostly engrave; the A1 costs half
• About $879 (list $1,099), check the live price

Both Creality boxes need ducting to a window. Class 1 means the light stays inside; it doesn’t mean the smoke does.

Avoiding the machines Linux can’t drive

Some of the best-selling engravers are a bad buy for a Linux-only household, and xTool is the clearest case. Its F2 page says the machine “currently works exclusively with xTool Studio (formerly XCS)”, and xTool Studio’s download page offers Windows and macOS only. The M2 page mentions only xTool Studio as well. The S1 is the exception that proves the point: LightBurn 1.7.00 added it as a native xTool device, so the frozen 1.7.08 Linux build can drive it. The same release note mentions an S1 “GRBL compatibility” mode, but I haven’t seen it driven from Rayforge or UGS, and xTool’s FAQ says LightBurn still lacks the S1’s curved-surface mode. That is a dead end with a nice view, because every fix from here on lands in 2.x.

They’re good machines. You’d just be keeping a Windows or Mac laptop next to them forever, and that’s not what someone searching for a Linux laser wants to hear after the box arrives.

Testing the Linux side before the laser arrives

Can you check your Linux setup before the laser ships? Yes, and it took me under an hour. GRBL has an official simulator that compiles the real firmware for x86 and reads G-code on stdin, so with socat it looks like a serial port to any sender. My first attempt cloned github.com/grbl/grbl, which turned out to be Grbl 0.9j; the 1.1 line that diode lasers run lives at gnea/grbl. Install the build tools first (vim is there because a stock Ubuntu desktop only has vi):

sudo apt-get install -y build-essential socat python3-serial python3-venv git flatpak vim

The simulator has to sit inside the firmware’s source directory, because its headers include ../system.h. Clone both and build:

cd ~
git clone https://github.com/gnea/grbl
cd grbl/grbl
git clone https://github.com/grbl/grbl-sim
cd grbl-sim
make new

On Ubuntu 26.04’s GCC the link failed with about thirty “multiple definition” errors and no binary:

/usr/bin/x86_64-linux-gnu-ld.bfd: ../protocol.o:/home/philip/grbl/grbl/grbl-sim/./avr/wdt.h:33: multiple definition of `wdt'; grbl_interface.o:/home/philip/grbl/grbl/grbl-sim/./avr/wdt.h:33: first defined here
/usr/bin/x86_64-linux-gnu-ld.bfd: system_declares.o:/home/philip/grbl/grbl/grbl-sim/system_declares.c:7: multiple definition of `sys_rt_exec_state'; ../main.o:/home/philip/grbl/grbl/grbl-sim/../main.c:30: first defined here

That’s GCC 10 and later defaulting to -fno-common, which old embedded code trips over. Adding -fcommon to the Makefile’s flags fixes it:

sed -i 's/^FLAGS = -g -O3$/FLAGS = -g -O3 -fcommon/' Makefile
make new

It built, but every reply arrived one command late, because stdin was buffered while the simulator polled the file descriptor. I fixed it by turning off stdin buffering at the top of platform_poll_stdin(). Open the file:

vim platform_LINUX.c

Add the two lines after uint8_t char_in=0; inside platform_poll_stdin(), then run make new again:

  static int unbuf=0;
  if (!unbuf) { setvbuf(stdin, NULL, _IONBF, 0); unbuf=1; }

Now give the simulator a serial port. This runs socat as a transient systemd unit owned by your user and links the pty to /tmp/ttyGRBL. Your shell expands $USER and $HOME before sudo sees them:

cd ~ && sudo systemd-run --unit=grblsim --uid="$USER" --working-directory="$HOME" socat -d -d PTY,raw,link=/tmp/ttyGRBL,echo=0 "EXEC:'$HOME/grbl/grbl/grbl-sim/grbl_sim.exe -n -s /tmp/step.out -b /tmp/block.out',pty,raw,echo=0"

Keep the --working-directory flag. My first run of the portable version left it out, the unit started in /, and the journal showed waitpid(): child 35568 exited on signal 11 with no /tmp/ttyGRBL ever appearing. Check with journalctl -u grblsim if the port is missing.

Grbl’s own doc/script/stream.py was my first choice of sender, and it died on Python 3.14 with SyntaxError: Missing parentheses in call to 'print', because it’s Python 2 code and 26.04 has no Python 2. So I wrote a tiny pyserial script that sends each argument and prints the reply. Create it:

vim ~/gsend.py

Paste this in. A real sender waits for each ok before sending more; this one just sleeps, which is fine for poking at settings:

import sys, time, serial
s = serial.Serial('/tmp/ttyGRBL', 115200, timeout=0.3)
s.reset_input_buffer()
args = sys.argv[1:]
if args and args[0] == '--reset':
    args = args[1:]
    s.write(b'\x18')
    time.sleep(1.5)
    print(s.read(4096).decode(errors='replace').strip())
for cmd in args:
    print('>>', cmd)
    s.write(cmd.encode() if cmd == '?' else (cmd + '\n').encode())
    time.sleep(0.8)
    out = s.read(8192).decode(errors='replace').replace('\r', '').strip()
    if out:
        print(out)

The --reset flag sends Ctrl-X, which makes GRBL print its banner. Ask for the build info and a status report:

cd ~ && python3 gsend.py --reset '$I' '?'

The banner, the version line and an Idle status are exactly what Rayforge or UGS look for when they connect to a real board:

Grbl 1.1h ['$' for help]
>> $I
[VER:1.1h.20190830:]
[OPT:V,15,128]
ok
>> ?
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Pn:PXYZRHS|WCO:0.000,0.000,0.000>

Out of the simulator, $32 is 0, which means spindle mode. On a laser that’s wrong, because GRBL then pauses motion at every power change and keeps the programmed power constant while the head slows into corners, so you get scorched dots. Turn laser mode on and read the three laser settings back:

python3 gsend.py '$32=1' '$$' | grep -E '^(>>|\$3[0-2]=|ok)'

$30=1000 is the S value that means full power, and $32=1 is laser mode. Every sender’s “max power” setting has to match $30, or 100% in the app won’t be 100% at the diode:

>> $32=1
ok
>> $$
$30=1000
$31=0
$32=1
ok

Then I streamed a 20 mm square with M4 S0 and G1 ... S600 F1500, polling ? as it ran. The status reports came back as FS:500,200 along the straight edges, not 1500 and 600. The simulator’s default $110 max rate is 500 mm/min, so GRBL clamped the feed, and in M4 dynamic mode it scaled the power down with the speed. That’s the behaviour you want from a laser, and it’s also why a job that looks too pale usually has a feed rate the machine can’t reach.

The last thing I checked was what a sender sees when something’s wrong. These are the codes Rayforge and UGS translate into messages for you:

error:22 is a G1 move with no feed rate set, error:20 is an unsupported G-code, and error:5 is $H with homing disabled ($22=0). The third one is the one I’d expect a new owner to hit first, because a sender’s Home button sends $H and stock GRBL ships with homing off.

When you’re done, stop the simulator. Systemd keeps the stopped unit in a failed state, and my next systemd-run refused with “Unit grblsim.service was already loaded or has a fragment file” until I cleared it, so run both:

sudo systemctl stop grblsim
sudo systemctl reset-failed grblsim

The /tmp/ttyGRBL link disappears with it, which is a quick way to confirm nothing is left running.

Connecting a real engraver to Ubuntu

Do you need a driver? No: when the laser arrives, the kernel already has what it needs. Older GRBL boards use a CH340 USB-to-serial chip, and the Ubuntu 26.04 kernel (7.0.0-15-generic in my VM) ships the ch341 driver with the CH340’s ID in its alias table:

modinfo ch341 | grep -E '^(filename|description|alias)' | head -12

The 1A86p7523 line is the CH340 that most Sculpfun-class boards carry, and it’ll show up as /dev/ttyUSB0:

filename:       /lib/modules/7.0.0-15-generic/kernel/drivers/usb/serial/ch341.ko.zst
description:    Winchiphead CH341 USB Serial driver
alias:          usb:v9986p7523d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4348p5523d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2184p0057d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v1A86p7523d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v1A86p7522d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v1A86p5523d*dc*dsc*dp*ic*isc*ip*in*

The thing that used to bite people is brltty, the braille display daemon. On Ubuntu 22.04 its udev rule claimed the CH340’s ID and the port vanished (Launchpad bug 1990357). I pulled the 26.04 package apart to see whether it still does:

cd /tmp && apt-get download brltty && dpkg-deb -x brltty_*.deb x && grep -n -i '1a86' x/usr/lib/udev/rules.d/*brltty*.rules | head

In brltty 6.7-1ubuntu6 both CH34x lines are commented out, with Ubuntu’s note pointing at bug 1958224, so a stock 26.04 desktop leaves your laser’s port alone:

Get:1 http://archive.ubuntu.com/ubuntu resolute/main amd64 brltty amd64 6.7-1ubuntu6 [1655 kB]
Fetched 1655 kB in 2s (884 kB/s)
83:# Device: 1A86:55D3
89:#ENV{PRODUCT}=="1a86/55d3/*", ENV{BRLTTY_BRAILLE_DRIVER}="hm", GOTO="brltty_usb_run"
91:# Device: 1A86:7523
96:#ENV{PRODUCT}=="1a86/7523/*", ATTRS{idVendor}=="1a40", ATTRS{idProduct}=="0101", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

If you’re still on 22.04 or an older Mint and the port never appears, remove brltty and reboot, which is the workaround in that bug report. Either way, your user needs to be in dialout to open the port without sudo; log out and back in after this:

sudo usermod -aG dialout $USER

For the sender, Rayforge from Flathub is the quickest route. If Flathub is new to you, the Snap vs Flatpak vs APT comparison for Ubuntu 26.04 explains the trade-offs, and Fedora users have their own Flatpak and Flathub setup guide. I installed it system-wide:

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install -y --noninteractive flathub org.rayforge.rayforge

Check what landed:

flatpak info org.rayforge.rayforge | head -12

Rayforge itself is 645.5 MB installed, but it pulls the GNOME 49 runtime with it, and my /var/lib/flatpak ended at 3.2 GB on a VM that had no other Flatpaks:

          ID: org.rayforge.rayforge
         Ref: app/org.rayforge.rayforge/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 1.13.1
     License: MIT
      Origin: flathub
Installation: system
   Installed: 645.5 MB
     Runtime: org.gnome.Platform/x86_64/49

MeerK40t taught me one more thing. It installed from pip in a venv and meerk40t --version printed MeerK40t 0.9.9100 pkg, but its headless mode crashed importing NumPy with RuntimeError: NumPy was built with baseline optimizations: (X86_V2) but your machine doesn't support: (X86_V2). My VM used QEMU’s generic kvm64 CPU model. A real desktop won’t hit that, but an old Atom-class box or a VM with a generic CPU will, so set the VM’s CPU type to host if you run your laser software in one. If you also flash microcontrollers for your shop, the Arduino IDE on Linux uses the same dialout group and serial ports.

What I still don’t know

I’m confident about the protocol and the Linux plumbing because I watched it work. I’m less sure about the parts that only a real machine on a real desk can settle:

• Whether the Falcon A1 camera aligns as well in Rayforge as it does in Creality’s own app
• The GRBL build string the four boards besides the Falcon A1 report to $I
• Whether the Atomstack’s Wi-Fi mode can be reached by anything except Atomstack’s app
• If LightBurn ever brings Linux back; a staff reply on its forum this month didn’t sound like it

If you own one of these and run it from Linux, the $I line is the most useful thing you could send me. Building a maker corner around a home server? The 3D printers for homelab parts sit happily next to a laser, and the Raspberry Pi and Arduino books list covers the electronics side when you start adding sensors and air-assist controllers.