Moonraker is the API layer Klipper printers did not have

A socket between firmware and web clients

Moonraker exposes an API for client applications that interact with the Klipper 3D printing firmware.

The mechanism is stated in one line in the README: communication between the Klippy host and Moonraker happens over a Unix Domain Socket. That choice matters for deployment. A Unix socket is local to the machine, so the trust boundary is the network in front of Moonraker rather than the socket itself, and anyone exposing Moonraker to a LAN or the internet is making that decision consciously.

Tornado provides the server. It is pinned with both a floor and a ceiling, `tornado>=6.2.0,<=6.5.8`, which is a pattern repeated across most of the dependency list and suggests a project that upgrades deliberately rather than tracking latest.

The runtime dependencies include `pyserial==3.4`, `python-periphery==2.4.1`, `inotify-simple==2.0.1`, `dbus-fast>=2.21.3, <=5.0.22`, and `distro==1.9.0`. This is a server that sits on a single board, and its dependencies say so.

No interface ships with it, which surprises people

The README says it plainly: Moonraker does not come bundled with a client, you will need to install one. What you get is an API server, and the front end is a separate project maintained by other people.

The listed clients are Mainsail from the Mainsail-Crew, Fluidd by Cadriel, KlipperScreen by jordanruthe, and mooncord by eliteSchwein. Each is a separate repository with its own release cadence and its own bugs.

That indirection has a practical consequence for anyone evaluating Moonraker on its own. The documentation you will actually read while using it is the client's documentation plus the Read the Docs pages for Moonraker, and the two evolve separately. The README itself points the changelog at moonraker.readthedocs.io rather than at a GitHub releases list, which reinforces that the documentation site is the source of truth for what changed.

If you are deciding whether to adopt Moonraker, the question to ask first is not whether the API is good but whether the client you want keeps working with your version of it.

Installation is documented as an image, not a command

The README contains no installation command. It does contain two supported routes.

The first is a preinstalled Raspberry Pi image. MainsailOS from Mainsail-Crew includes Klipper, Moonraker and Mainsail together, and FluiddPi from fluidd-core includes Klipper, Moonraker and Fluidd.

The second is Docker. The README names prind by mkuf as a suite of containers for running Klipper in Docker, with support for both OctoPrint and Moonraker.

If you are installing from source, the packaging metadata is where the constraints live:

requires-python = ">=3.10"
license = {text = "GPL-3.0-only"}

The classifiers list Python 3.10 through 3.14, and the project status is declared as `Development Status:: 4 - Beta`,

The build configuration shows a modern Python layout: `pdm_build.py` for the build backend, a `uv.lock` for dependency resolution, `pytest.ini` for tests, `.pre-commit-config.yaml` for hooks, and `mkdocs.yml` with the `docs/` directory for the site built with mkdocs-material. Dev dependencies are grouped separately as pre-commit, mypy, ruff and build, so the documentation toolchain does not pollute the runtime environment.

The dependency list is the feature list

Reading the runtime dependencies tells you more about Moonraker's scope than the README does.

The dependency list also includes `paho-mqtt`, `zeroconf`, `apprise`, `libnacl`, `ldap3`, `jinja2`, `pillow`, `streaming-form-data`, and `preprocess-cancellation`.

That combination points at a server designed for a home network with several consumers: a dashboard, a phone notification, an automation system and possibly remote access with authentication in front.

The optional extras are about speed rather than features. `msgspec` is a faster serialiser, `uvloop` is a faster asyncio loop, and a `speedups` extra pulls both in.

Version numbers here will mislead you

The tags stop at v0.7.1, dated 2021-07-08, whose title is a fix for `git_repo` clients. Before it sits v0.7.0, a beta deployment release, also on 2021-07-08, and v0.1.0, the initial beta release, on 2020-09-01.

The last push was on 2026-09-29 and the repository is not archived. So the honest reading is that the project is developed continuously while its version tags on GitHub are not current. If you install by tag, you get a build from the release dates listed in the repository; installing from source gives you a different version-selection problem.

That is a documentation and release-process gap rather than a sign of abandonment, but it does mean version pinning from GitHub is not a reliable strategy for this project. The Pi images and the container route sidestep the question entirely, which may be why the README leads with them.

On licensing, `pyproject.toml` states GPL-3.0-only and a `LICENSE` file sits at the repository root. For anyone shipping a modified Moonraker in a commercial product or appliance image, that text governs and is worth reading before distribution rather than after.

There is a `SECURITY.md` at the root for responsible disclosure, which is the right thing for a network-exposed service to have.

Editorial conclusion

Adopt Moonraker if you run Klipper and want remote control and monitoring from a browser, installing it through MainsailOS, FluiddPi or a container rather than from source tags. Do not pick a release number from GitHub to judge maturity, because the newest tag is v0.7.1 from 2021-07-08 while the last push was on 2026-09-29. Verify first that your Python is 3.10 or newer, since `requires-python` sets that floor, and read GPL-3.0-only in pyproject.toml before you redistribute anything built on it.

Frequently asked questions

Official sources

1. Arksine/moonraker on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases