OpenLinkHub drives Corsair LINK hubs and AIOs from a browser on Linux

It started because a workstation needed fan control on Linux

OpenLinkHub is an open source Linux interface for iCUE LINK hubs and other Corsair AIOs and hubs, managing RGB lighting, fan speeds and system metrics, as well as keyboards, mice and headsets, through a web dashboard.

The README's Info section explains the origin in one line: the project was created out of necessity to control fans and pumps on workstations after switching everything to Linux. That origin explains both the scope and the tone. The scope is the hardware Corsair's iCUE software supports, so a device list is part of the documentation, with a dedicated docs/supported-devices.md file. The tone is that of a working utility rather than a product, and it says so directly: the author takes no responsibility for the code at all, use it at your own risk, most of the devices are actually tested on live hardware, and this project is not an official Corsair product.

The web interface is served at http://localhost:27003, and the feature list covers control of AIO coolers, fans, hubs, pumps, LCDs and RGB lighting, plus management of keyboards, mice and headsets. Beyond that there is support for DDR4 and DDR5 memory, custom fan profiles, temperature sensors and an RGB editor.

The project is GPL-3.0 licensed, and the repository is not archived with the last push on 2026-10-18. Releases 0.9.0, 0.9.1 and 0.9.2 came out on 2026-08-05, 2026-08-23 and 2026-09-26, so it is on a 0.9 line that is still moving.

There is also a Portuguese translation of the README, which is a small sign of a user base outside the author's own locale.

The service talks to the hardware over USB and libusb

The mechanism is direct USB access rather than a driver, and the dependency list shows it.

The Go module requires sstallion/go-hid, a HID library, along with godbus/dbus/v5 for desktop bus communication, golang/freetype and golang.org/x/image for font rendering, which is what you need for text on an LCD panel, and golang.org/x/sys and golang.org/x/text as supporting dependencies. The module path is simply OpenLinkHub and it requires Go 1.25.0.

Because the service opens the devices directly, it needs udev rules to be allowed to see them. The repository contains a 99-openlinkhub.rules file, and the installation script copies it to /etc/udev/rules.d/. The Docker image also writes a separate rule for the memory bus, a line setting the mode and owner for KERNEL=="i2c-0" with the owner set to openlinkhub, plus a modules-load.d entry for i2c-dev.

That i2c detail matters for the memory features. Reading the temperature of DDR4 and DDR5 memory over an SMBus requires access to the i2c bus, which is why the config has a memorySmBus field with a value like i2c-0, and why the Docker image sets up the udev rule and loads the i2c-dev module explicitly.

The udev rule and the group are what make the arrangement workable. The recommended installer creates a system group named openlinkhub, adds your current user to it, installs the application in your home directory, creates a user systemd service, copies the udev rule, and starts the service. A user service rather than a system one is a reasonable choice, since the group membership gives device access without the daemon running as root.

A JSON file configures everything, and there is no settings UI

The configuration is a single JSON file at /opt/OpenLinkHub/config.json, and the README documents the fields in detail. The excerpt in the README shows the shape:

{
  "debug": false,
  "listenPort": 27003,
  "listenAddress": "127.0.0.1",
  "cpuSensorChip": "k10temp",
  "manual": false,
  "frontend": true,
  "metrics": true,
  "resumeDelay": 15000,
  "memory": false,
  "memorySmBus": "i2c-0",
  "memoryType": 4,
  "exclude": [],
  "decodeMemorySku": true,
  "logLevel": "info",
  "amdGpuIndex": 0,
  "nvidiaGpuIndex": [0],
  "enableGamepad": true,
  "enableMotherboard": false
}

Several of these carry decisions rather than just values. The listenAddress defaults to 127.0.0.1, so the dashboard is local only, and listenPort is the HTTP server port. cpuSensorChip selects the CPU temperature source, with k10temp and zenpower for AMD and coretemp for Intel. The metrics switch turns Prometheus metrics on or off, which is a nice touch for a service like this. resumeDelay is the number of milliseconds the program waits before reinitialising all devices after a sleep or resume, which is a real problem for USB peripherals that get power-cycled.

The manual flag is the one to read carefully. Setting it to true means you will use your own UI for device control, and it disables temperature monitoring and automatic device speed adjustments. The frontend flag is similar: set it to false if you do not need the web console because you are building your own UI app. In other words, the project is designed so that the hardware control layer can be reused without the web frontend, which is the shape you want if you are writing your own dashboard.

The memory settings form a small group of their own. memory enables the overview and control over memory, memoryType is 4 for DDR4 and 5 for DDR5, memorySmBus is the i2c sensor id, decodeMemorySku lets the program read the part number itself and can be turned off to define memorySku manually, and exclude is a list of device IDs in uint16 format to keep out of the program's control. The README also documents motherboard PWM, GPU index selection for both AMD and Nvidia, gamepad support and a motherboard BIOS restore on exit.

Four install routes, and one of them exists because of immutable distributions

The recommended route is a single piped script:

curl -fsSL https://raw.githubusercontent.com/jurkovic-nikola/OpenLinkHub/main/remote-install.sh | bash

The README explains what it does: it creates the openlinkhub group, adds your user, installs OpenLinkHub in your home directory, creates a user systemd service, copies the udev rules, and starts the service. The same script handles upgrades, and the README tells you to uninstall any previous version before running it.

For distribution packages there are deb and rpm files on the Releases page, installed with apt install ./OpenLinkHub_?.?.?_amd64.deb or dnf install ./OpenLinkHub-?.?.?-1.x86_64.rpm. There is a Launchpad PPA for Ubuntu and a COPR repository for Fedora.

The manual route needs libudev-dev, usbutils, libpipewire-dev, pkg-config and Go 1.25.0, and the build needs a specific flag:

$ git clone https://github.com/jurkovic-nikola/OpenLinkHub.git
$ cd OpenLinkHub/
$ CGO_CFLAGS_ALLOW='-fno-strict-overflow' go build .
$ chmod +x install.sh
$ sudo ./install.sh

The flag is not arbitrary. The Dockerfile explains it in a comment: libpipewire-0.3.pc advertises -fno-strict-overflow, which is not on cgo's list of accepted compiler flags, so the pkg-config output alone fails the build. The Docker image sets the same environment variable for the same reason, which is a nice example of a workaround being documented rather than left as folklore.

Then there is the immutable distribution path, and the README is emphatic about it: do not install RPM or DEB packages on immutable distributions, they will not work. For Bazzite OS, SteamOS and similar, you download the tarball, extract it into your home directory, make install-user-space.sh executable and run it, which asks for your password once to copy the udev rule. After a reboot you check it with systemctl status --user OpenLinkHub.service, and on a normal distribution you start it with sudo systemctl start OpenLinkHub.service and open http://127.0.0.1:27003. A devcontainer in VScode is offered as another way to get the build environment, which the README says is useful for immutable distributions.

Related projects fill the gaps in the official client

The repository is the core of a small family of tools, and the README links several of them.

There is a system tray menu in a separate repository, openlinkhub-tray, for people who want the controls in the notification area rather than a browser tab. There is a KDE System Monitor sensor face project, openlinkhub-sensorfaces, which puts the readings into the panel. There is a documentation page for the XENEON EDGE KDE integration, and a SCUF Controller audio config page, which is about the audio side of the SCUF controllers rather than the lighting.

The OpenRGB integration has its own directory with a README, which is a notable inclusion because OpenRGB is the established cross vendor RGB daemon on Linux. Having OpenLinkHub cooperate with it means the Corsair devices can be driven by the same tool that drives everything else, which is the more composable outcome for anyone who already uses OpenRGB.

The api/ directory and the web/ directory in the tree suggest that the web interface is backed by an API layer rather than being server rendered pages, and static/ holds the frontend assets.

The project also tracks a CHANGELOG.md at the top of the repository, and the OpenLinkHub.service and OpenLinkHub.init files are the systemd unit and the init script. A separate upgrade.sh is present for updating an existing installation.

What is not in the repository is a client application. The dashboard is served by the same process that talks to the hardware, and the config file has no options for a Corsair-style desktop application, so on Linux the browser is the interface.

Where OpenLinkHub is the wrong choice

The first limit is device coverage. The supported device list is a document in the repository rather than a promise, and a reimplementation of a vendor protocol will support some models and not others, with new hardware revisions often behaving differently. The README's claim that most devices are tested on live hardware is reassuring but it is not the same as a coverage guarantee, and the device you own is the one that matters.

The second is the absence of a vendor client on Linux in the first place. If Corsair's iCUE works on your platform, or if your peripherals are supported by OpenRGB, then this project is solving a problem you do not have, and the honest comparison is against those tools rather than against nothing.

The third is the risk posture. The README says plainly that the author takes no responsibility and to use it at your own risk, and the service needs udev rules that grant access to USB and i2c devices, plus a user service in your home directory. That is a reasonable design, and it is still an unowned service with direct hardware access on a machine that is probably your workstation.

The fourth is the configuration surface. Everything is a JSON file edited by hand, with no setup wizard. For a first install that means you are guessing at field names from a README table, and the fields are not all self explanatory, particularly the GPU index settings for AMD and Nvidia and the memorySku decoding toggle. A user who wants the browser dashboard to just show their fans running will not get that without reading the configuration documentation first.

Editorial conclusion

OpenLinkHub suits a Linux user with Corsair LINK hardware who needs fan curves, RGB and LCD control that Corsair's own software does not provide on that platform, and it is the wrong tool for anyone whose peripherals are supported by a working vendor utility, since this is a reimplementation rather than a driver. Before installing, read the device support list, because coverage varies by model, and check the udev rules the installer copies, because the service needs device access. Verify first whether the hub you own is on the list, and note that the project ships no configuration UI in the official client, so the initial setup is editing a JSON file.

Frequently asked questions

Official sources

1. jurkovic-nikola/OpenLinkHub on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases