Lightworks runs natively on Linux, and its maker publishes a Fedora RPM on a public CDN that you can download without logging in. To install Lightworks on Fedora today you need one dnf command. The RPM Fusion repository and the separate libCg package that older guides add are not needed any more, because the package now carries its own Cg, FFmpeg and OpenCL libraries. What you can’t skip is the free lwks.com account, because the first-run wizard in this build offered no guest route and won’t move past its sign-in step without one.
Below, we install the official Lightworks Linux RPM, prove no library is missing and start it on GNOME Wayland. Then come the first-run wizard, three launch errors and a clean removal. Every command was run on Fedora 45 Workstation in November 2026 with Lightworks 2026.1.0, and the same RPM was installed on Fedora 44 as a cross-check.
Check what Lightworks needs
Lightworks is a desktop app, so it wants a desktop session and a working OpenGL stack rather than a server install. The vendor’s installation and setup page asks only for a modern multi-core CPU, a GPU with current drivers, plenty of RAM and fast storage, and it gives no hard minimums. Before you start, have these in place:
- Fedora Workstation (GNOME) or another Fedora desktop on x86_64
- A user with sudo rights
- About 480 MiB free for the package, plus room for media
- An lwks.com account (the Free plan works)
- GPU drivers that provide OpenGL and, for the newer scopes, OpenCL
The Free plan exports up to 1080p, and the pricing page lists 4K export and BRAW decode under Create, with 8K, HDR and ProRes encode under Pro. The same page marks four items as not available on Linux (the advanced transitions, advanced titles, advanced correct and enhance tools, and the TotalFX upgrade) and warns that some Linux functionality may be restricted by third parties, so check it if you rely on those. Our lab VM had no GPU at all and Lightworks still started on Mesa’s software renderer, which is fine for following this guide but far too slow for real editing.
Download the Lightworks RPM
The download page at lwks.com links to a latest alias on the vendor CDN, and that URL always points at the current Linux build. Pull it straight into your home directory:
cd ~
curl -LO https://cdn.lwks.com/releases/latest/lightworks_linux_rpm.rpmThe file is about 130 MiB. Before installing anything, read the package header so you know which build you got:
sha256sum lightworks_linux_rpm.rpm
rpm -qpi lightworks_linux_rpm.rpm | head -12Our download was version 2026.1.0, release 1153, built on 14 October 2026. Two lines in that header matter. Signature : (none) means the RPM is not GPG signed, so the only thing tying it to the vendor is the HTTPS download from cdn.lwks.com; never install a copy mirrored somewhere else. Build Host : fedora35build01 tells you the binary was built on an old Fedora and carries its own libraries to stay portable, which explains why it installs so cleanly on current releases:
The SHA-256 above belongs to that one build. The latest URL moves with every release, so expect a different hash when a newer Lightworks is out, and use the header’s version line to confirm what you’re about to install.
Install Lightworks with dnf
Install the local file with dnf rather than rpm -i, because dnf resolves the handful of dependencies from the Fedora repos for you. No extra repository is needed:
sudo dnf install -y ./lightworks_linux_rpm.rpmOn a Workstation install, dnf pulled in only six packages, all from the gtkmm C++ binding stack (gtkmm3.0, glibmm2.4, cairomm, pangomm, atkmm and libsigc++20), and the whole transaction added 479 MiB. The OpenPGP warning near the end is the unsigned package from the previous step, and it does not stop the install. Our run also printed that a pending offline transaction had been invalidated: if GNOME Software had an update staged for the next reboot, this dnf transaction cancels it, so open Software afterwards and let it download the update again.
Then confirm the package is registered:
rpm -q lightworksIt answers with the full version and release string:
lightworks-2026.1.0-1153.git9474ab5e.x86_64We ran the same RPM, byte for byte, on both current Fedora releases. The only difference was how much of the desktop stack was already there, since the older-release VM was a minimal cloud image with no GNOME:
| Check | Fedora 45 Workstation | Fedora 44 (minimal, no desktop) |
|---|---|---|
| RPM SHA-256 | ac5fc1ee…85076d | ac5fc1ee…85076d |
| Packages installed | 7 (Lightworks plus 6) | 233 (GTK, ALSA, Mesa and the rest) |
| Extra repositories | None | None |
ldd “not found” lines | 0 | 0 |
| Kernel during the test | 7.2.15-300.fc45 | 7.2.13-200.fc44 |
If you run a spin other than Workstation, expect a dependency list somewhere between those two numbers. It is still one command either way.
Confirm no library is missing
The classic failure on older Fedora releases was a shared library the binary couldn’t find, usually libCg, which sent people to RPM Fusion. You can rule that out in two commands before you ever click the icon. The first shows which libraries the package claims to provide itself:
rpm -q --provides lightworks | grep -E "Cg|avcodec|OpenEXR"The second asks the dynamic linker to resolve every library the main binary, ntcardvt, links against and prints anything it can’t find:
ldd /usr/lib/lightworks/ntcardvt | grep "not found" || echo "no missing libraries"Both checks came back clean in the lab. NVIDIA’s Cg runtime, FFmpeg’s libavcodec.so.61 (Fedora itself ships a newer FFmpeg), OpenEXR and even an OpenCL ICD loader are all provided by the package itself, and the screenshot’s extra ldd filter shows Cg and OpenCL loading from /usr/lib/lightworks. Of the lines in that filter, only libGL.so.1 comes from Fedora; the GTK, glibc and ALSA libraries behind the rest of the 186 resolved entries are ordinary system packages. That is why the old RPM Fusion step is gone.
Bundling has a side effect you’ll meet again at removal time: because the RPM advertises those private libraries as Provides, dnf may satisfy another package’s dependency with the copy inside Lightworks. You still want RPM Fusion for codecs in other players and editors, and our RPM Fusion codecs guide covers that separately from Lightworks.
Launch Lightworks on Wayland
Open Activities, type lightworks and click the launcher. We took this capture after the first start, so the search also lists the Lightworks folder the app creates in your home directory for projects, preferences and logs:
Fedora’s GNOME runs only Wayland sessions, and Lightworks is not a Wayland client. Its launcher script forces the X11 backend, so on GNOME the editor always runs through Xwayland. You can confirm that from a terminal inside your desktop session:
cat /usr/bin/lightworks
xlsclients
glxinfo -B | grep -E "renderer|core profile version|Accelerated"xlsclients and glxinfo come from the xlsclients and glx-utils packages (sudo dnf install xlsclients glx-utils) if you do not have them. The launcher sets GDK_BACKEND=x11 and GDK_SCALE=1, and ntcardvt shows up as an X11 client next to mutter’s own window frames. The renderer line is the one to read on your machine: our VM reported llvmpipe with Accelerated: no, which is software rendering. On real hardware you want your GPU’s name there, and if you see llvmpipe on a desktop with a graphics card, fix the driver before blaming Lightworks for slow playback.
On a KDE Plasma Wayland session the launcher script is the same, so Lightworks goes through Xwayland there as well; our note on the Plasma move from X11 to Wayland explains what that changes for older apps. We only ran it on GNOME.
Run the first-run wizard
The first start opens a short wizard, and its second screen is where Lightworks makes you choose an account route. Step 1 is the interface language, with English preselected; the wizard’s own note says you can change it after installation:
Step 2 states it plainly. To get started you need an lwks.com account. The vendor’s setup page mentions a limited guest period, but this build on Linux showed no guest or offline option on this screen, only two routes into an account:
- Select I already have an account if you’ve registered before.
- Click Next to open the sign-in form.
- 1I already have an account
- 2Next
The default choice, I’d like to make a new account, swaps the sign-in form for a registration form asking for your name, email address, username and password. You can fill it in here, or register in a browser at app.lwks.com/register and come back to take the sign-in route. Either way, use an email address you can read, since the account is what carries your licence:
The sign-in step takes your lwks.com username or email address and password. Next is greyed out until Sign in succeeds, and that’s the hard gate. Without an account the wizard ends here, at step 3 of 5.
Your licence follows the account, so signing in with a Create or Pro account unlocks those features on this machine too. Settings live in ~/Lightworks/Preferences/UserSettings.txt, and the app keeps its projects folder at ~/Lightworks/Projects.
Fix the launch errors we hit
None of these came from a missing package. All three are about how Lightworks talks to the display, and each one has a short fix.
Authorization required, but no authorization protocol specified
Starting lightworks from an SSH session or another shell where DISPLAY points at the desktop but XAUTHORITY is not set crashes it immediately. Our first launch over SSH did exactly that:
Authorization required, but no authorization protocol specified
13:19:34.542 runtime resources directory /usr/share/
/usr/bin/lightworks: line 4: 3668 Aborted (core dumped) LD_PRELOAD=libmimalloc.so LD_LIBRARY_PATH=/usr/lib/lightworks GDK_BACKEND=x11 GDK_SCALE=1 /usr/lib/lightworks/ntcardvtXwayland on GNOME only accepts clients that present the cookie mutter writes under /run/user/<uid>/, and that shell has no XAUTHORITY pointing at it. Launch from Activities or a terminal opened inside the desktop. If you really need to start it from another shell as the same user, export the display and the newest cookie first. The display was :0 in our lab, and echo $DISPLAY in a desktop terminal confirms yours:
export DISPLAY=:0
export XAUTHORITY=$(ls -t /run/user/$(id -u)/.mutter-Xwaylandauth.* | head -n1)
lightworksWith only those two variables set, the same SSH launch stayed up and opened the wizard on the desktop. Unset XAUTHORITY again and the authorization error comes straight back.
Lightworks closed unexpectedly in the previous run
After any crash or a killed process, the next start opens this prompt before the wizard:
It’s harmless. Click No unless you want to send logs to the vendor, which includes your username. The logs stay in ~/Lightworks/Logs either way if you want to read them yourself first.
Tiny window on a fractionally scaled display
With the display set to 150% in GNOME Settings, the wizard came up at roughly two thirds of its normal size, pushed into the top left corner. GNOME lets X11 apps draw at the panel’s native resolution so HiDPI-aware ones stay sharp, but the launcher pins GDK_SCALE=1, so Lightworks never scales itself up. Telling mutter to scale X11 windows instead fixes it:
gsettings set org.gnome.mutter.wayland xwayland-scaling-factor 1.0Quit Lightworks before you change the key and start it again afterwards. In our lab, Xwayland was not running when the key changed, so it started fresh with the new factor and the wizard filled the window at the right size. If other X11 apps are open, log out and back in so Xwayland restarts. The price is a slightly soft Lightworks UI, which beats a dialog you have to squint at. gsettings reset org.gnome.mutter.wayland xwayland-scaling-factor puts the automatic default back.
Remove Lightworks cleanly
Removal is a normal dnf transaction, but read the list before you confirm it, because the bundled libraries can drag something else out with it. Drop the -y so dnf asks first:
sudo dnf remove lightworksIn the lab, dnf also wanted to remove clinfo, which we had installed after Lightworks to check OpenCL. Its dependency on libOpenCL.so.1 had been satisfied by the loader inside Lightworks instead of the system ICD loader, so it went out as a dependent package along with the six gtkmm libraries.
If a package you want to keep shows up under “Removing dependent packages”, answer no, install ocl-icd so the system has its own OpenCL loader, and run the removal again. We checked that: once ocl-icd was in place, clinfo dropped off the removal list. The RPM also leaves your data behind on purpose:
~/Lightworks/Projectswith every project and its database~/Lightworks/Preferenceswith your settings~/Lightworks/Logsand~/Lightworks/Media
That folder was only 92 KB on a fresh install, but it grows with every project, so copy out anything you still need before you delete it for good:
rm -rf ~/Lightworks ~/lightworks_linux_rpm.rpmIf you’re setting up a fresh Fedora desktop for video work, the things to do after installing Fedora 45 checklist covers drivers and codecs first. The same Lightworks build ships as a DEB, and our Lightworks guide for Ubuntu, Debian and Mint follows it through to a first project. If you’re still choosing an editor, the Filmora vs Lightworks comparison weighs the effects each one gives you.
