Mixxx: Free DJ Software for Live Mixing on Linux, Windows and macOS

What Mixxx Solves and Who It Is Built For

The README states the scope in one line: Mixxx is Free DJ software that gives you everything you need to perform live DJ mixes, and it works on GNU/Linux, Windows and macOS. That sentence is the whole product claim. The target user is a working or aspiring DJ who wants to mix tracks live on hardware they already own, without paying for a licence and without being locked to one operating system.

The Linux support is the part that separates Mixxx from most of the field. Commercial DJ applications are typically Windows and macOS products, sometimes with a Linux build that lags behind. Mixxx treats GNU/Linux as a first-class platform, which matters if your performance machine is a Linux laptop or a small single-board computer. The topics attached to the repository list audio, dj, hid, linux, mac, midi, music, qt and windows, which tells you the integration surface: MIDI and HID controllers, Qt for the interface, and the three desktop platforms.

It is not a music production tool. There is no arrangement view, no plugin hosting for virtual instruments, and no rendering pipeline for finished tracks. If your work happens before the gig rather than during it, this is the wrong category of software.

How Mixxx Is Put Together: C++, Qt and a Controller Layer

The primary language is C++, and the repository root carries CMakeLists.txt alongside a cmake/ directory, so the build system is CMake. Qt appears both in the repository topics and in the file listing: there is a .qmlformat.ini at the top level, which points to QML being used for parts of the interface. A res/ directory sits next to src/, which is where skins and other runtime resources live, and lib/ holds bundled dependencies.

The controller story is visible in the topics rather than the README. MIDI and HID are both listed, which means the application talks to controllers over the two protocols that cover the majority of DJ hardware. The README links a Hardware Compatibility page, and that page, not the README, is where you find out whether a specific device works. This is the right place to look first, because controller support in Mixxx is community-driven: mappings are contributed, and a device that is not listed is a device nobody has written a mapping for yet.

The build tooling is unusually broad for a desktop application. The top level contains .clang-format, .clang-tidy, .codespellignore, .flake8, .prettierrc.yaml, .markdownlint-cli2.yaml, eslint.config.cjs, .pre-commit-config.yaml and a pyproject.toml that configures black with a line length of 79. That mix of C++, Python, JavaScript and configuration linters tells you the project enforces style across several languages, and CONTRIBUTING.md is where the README sends anyone who wants to build it.

Installing Mixxx and Mixing Your First Two Tracks

The README does not give package manager commands. It gives three routes and expects you to pick one. For live use it points to the stable download page; for experimentation it points to a development release; and for the bleeding edge it gives a git clone of the repository. If you are going to perform with it, take the stable download. Development releases are described as being for experimentation and testing.

The clone command from the README is the starting point only if you intend to build from source:

git clone https://github.com/mixxxdj/mixxx.git

Cloning gives you the source tree, not a runnable application. The README says to read CONTRIBUTING.md for build instructions, code style guidelines, and how to open a pull request, and that file is where the actual compile steps live. Nothing in the README documents a one-line build, so budget real time for dependencies if you go this route.

Once Mixxx is installed, the workflow is the standard two-deck layout. Load a track into each deck, start the transport on one, and bring the second in with its channel fader. The README does not walk through this, and it does not need to: the Mixxx manual is linked from the README as the place for help using Mixxx, and it covers the interface in detail.

If you want the application to keep playing without you, the Auto DJ feature is the relevant one. It is one of the phrases people search for alongside the project name, and it is the feature that lets a set continue while you deal with a problem or take a break. The README does not document its configuration, so treat the manual as the source of truth for how the queue behaves.

Where Mixxx Falls Short and When to Pick Something Else

The README is a contributor document, not a user guide. That is a deliberate choice and it has a cost: there are no installation commands, no first-run walkthrough, no explanation of Auto DJ, and no troubleshooting section. Everything a new DJ needs is pushed to the manual, the wiki and the hardware compatibility page. If you are the kind of user who wants the repository to answer your questions, it will not.

Controller support is the sharpest limitation. MIDI and HID are listed as topics and a hardware compatibility page exists, but support is mapping-driven and community-maintained. A controller that is not in that list is a controller you will be mapping yourself, and the README does not describe the mapping format. Buy hardware that is already documented, or accept that you are signing up for unpaid integration work.

The licence is listed as GPLv2 in the README, while the repository metadata reports the licence as NOASSERTION. If licence terms matter to your organisation, read the LICENSE file and the COPYING file in the repository root rather than trusting the metadata field, and get your own legal review. Nothing here is legal advice.

Finally, Mixxx is not a substitute for a DAW, and it is not a streaming service integration. The README makes no claim about Spotify or any other streaming catalogue, and there is no such feature documented in it. If your plan depends on pulling tracks from a subscription service inside the DJ application, verify that separately before committing.

Mixxx Compared with Serato and rekordbox

The honest comparison is not about features, it is about who controls the hardware relationship. Serato and rekordbox are commercial products whose controller support is negotiated with manufacturers. When a new controller ships, the commercial vendor and the hardware maker coordinate so the device works on day one. Mixxx has no such arrangement. Its support comes from contributors who own the hardware and write the mapping, which means coverage is uneven and new devices can wait.

What you get in return is different. Mixxx runs on GNU/Linux, which neither of the commercial options treats as a primary platform. You can read the source, build it yourself from the CMake tree, and run it on hardware the vendors never targeted, including a Raspberry Pi, which is one of the search phrases associated with the project. For a Linux user, that is not a minor advantage; it is the reason to choose Mixxx at all.

The trade-off is support. With a commercial product you have a vendor to escalate to. With Mixxx you have GitHub Issues, a Zulip chat and a Discourse forum, all linked from the README, and a community of hackers, DJs and artists, as the README puts it. That community is responsive by open source standards, but it is not a contract.

Maintenance, Releases and the Cost of Upgrading

The last push to the repository was on 2026-09-21, so the project is under current development. The most recent release listed is 2.5.6 from 2026-03-27, preceded by 2.5.4 on 2025-12-14 and 2.5.3 on 2025-09-02. That is a patch-oriented cadence on the 2.5 line, roughly one release per quarter in the recent history, with the 2.5 series carrying the stable download link.

For a working DJ, the upgrade decision is straightforward: stay on the stable channel and move when a new stable release appears. Development releases exist and the README points to them, but it describes them as being for experimentation and testing, which is the correct framing. A development build is not what you want on the machine you perform with.

If you build from source, your upgrade cost is the cost of rebuilding: pulling the repository, re-resolving the CMake dependencies, and compiling. The README does not promise ABI or configuration stability across versions, and it does not document a rollback procedure. Keep a known-good stable install alongside any source build so you have something to fall back to.

The licence is GPLv2 per the README. For most DJs this changes nothing. For anyone embedding Mixxx in a product, redistributing a modified build, or shipping it on hardware, GPLv2 has obligations around source availability that you should review with a lawyer. The repository metadata reports NOASSERTION, so read LICENSE and COPYING directly.

Editorial conclusion

Adopt Mixxx if you want a GPLv2 DJ application that runs on GNU/Linux, Windows and macOS and you are willing to check the hardware compatibility list before buying a controller. Do not adopt it if you need a vendor support contract or a guaranteed response time on a bug, because the project routes everything through GitHub Issues and community chat. Before your first gig, verify three things: that your controller appears in the hardware compatibility documentation, that your audio interface works under your distribution's packaging of the current stable release, and that the version you installed matches the stable download rather than a development build.

Frequently asked questions

Official sources

1. Issues
2. mixxxdj/mixxx on GitHub
3. Project website
4. README
5. Releases