How to Manage LightBurn Files Across Multiple Computers

Most commercial laser shops hit the same wall once they grow past one machine or one operator. LightBurn is excellent design and machine control software, but it has no built-in way to sync projects, settings, or material libraries across computers.

As one LightBurn forum user put it: "I design on a computer in my office and control my laser from another in the shop. If I change a setting in my office, I'd like the same settings to be applied on the shop computer."

The result: operators open the wrong file version, material presets do not match, fonts are missing on the machine computer, and nobody can prove exactly what the customer approved.

The most common first instinct is to put LightBurn files on Google Drive, Dropbox, or a NAS. This works for most software. It does not work reliably with LightBurn. The LightBurn team has explicitly warned against it: "We've seen empty files, data loss and damage from other shared files."

The technical reason: cloud sync services monitor files for changes and upload them mid-save. LightBurn writes files in a way that can conflict with this process, resulting in empty 0-byte files, corrupted project data, or backup files that block saves.

Specific documented problems include: Dropbox grabbing files during save and preventing LightBurn from completing the write; Synology Drive sync creating empty files that destroy hours of work; and material library paths breaking because LightBurn stores absolute file paths that differ between computers.

Without a dedicated tool, most shops cobble together a workflow from generic tools:

• -USB drives: Copy the .lbrn2 file to a thumb drive and walk it to the machine. Simple but creates version confusion when files get updated.
• -Local network share: Map a network drive and save files there. Better than USB, but still risks the cloud-sync corruption issue if any sync service touches that folder.
• -Export/Import preferences: LightBurn lets you export preferences via File > Export Prefs. You can transfer this file to other computers. But you have to remember to do it every time you change a setting.
• -Email or Slack: Send the file to the operator. Creates a trail of "final_v3_REAL.lbrn2" messages with no clear record of which one was actually approved.
• -Separate LightBurn instances: Some shops install LightBurn twice or run multiple instances to handle different machines. Workable but fragile.

The file itself is only part of the problem. For an operator to run a job correctly, they need:

• -The correct version of the .lbrn2 file (not last week's revision)
• -All linked assets: fonts, SVGs, images, and any referenced files
• -Material presets: power, speed, passes, and any per-material settings
• -Machine configuration: which device profile, which origin setting
• -Customer approval record: proof of what was signed off, when
• -Job notes: special instructions, material handling, packaging requirements

When any of these are missing or wrong, the result is wasted material, remake costs, and frustrated operators.

Even after files reach the machine, organization is limited. Ruida controllers (used in many CO2 lasers) store files in a flat list with no folders and limited sorting. One shop owner described the file list as showing files in a scrambled order: "A1 A2 F1 A3 F2 F3 A4 A5 etc."

Operators looking for a specific job have to scroll through an unsorted list on a small controller screen. At scale, with hundreds of jobs per month, this becomes a real bottleneck.

Version confusion is the single most expensive problem in multi-operator shops. Customer approves one design, operator cuts a different version, and the shop eats the material cost.

Most shops have no systematic way to track which version was approved. The approval lives in an email thread, a text message, or a verbal confirmation. Six months later when the customer wants a reorder, nobody can find the exact file that was originally run.

A proper version control system for laser jobs would track every revision, tie approvals to specific versions, and make it impossible for an operator to pull an unapproved file.