# OpenNept4une: a Klipper Linux image for the Elegoo Neptune 4

> OpenNept4une replaces the Elegoo-supplied software on Neptune 4 printers with a custom Armbian image running Klipper, Fluidd, mainsail and Orca slicer profiles. It suits owners who already know Klipper and want the printer to behave like an open machine.

**OpenNeptune3D/OpenNept4une** — Transform your Neptune 4 3D printer with OpenNept4une, a collection of scripts designed to replace the manufacturer's software, reverting to the original open-source projects for enhanced performance, reliability, and features.

- Repository: https://github.com/OpenNeptune3D/OpenNept4une
- Stars: 683 · Forks: 64
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/openneptune3d-opennept4une

## What OpenNept4une removes from a Neptune 4

OpenNept4une is a collection of scripts and images that take a Neptune 4 series printer and move it off the manufacturer's software. The project description frames this plainly: the scripts are designed to replace the Elegoo software stack and revert the printer to the original open source projects it was built on. That means Klipper for motion control, moonraker as the API layer, Fluidd and mainsail as browser interfaces, kiauh for installing and updating Klipper, and KAMP for adaptive meshing and purging. The printer's own board still runs the same MCU firmware, but the Linux side of it becomes a normal small Linux computer you can ssh into.

The stated target audience is the kind of user who is annoyed by an opaque phone app and wants print logs, macros and webcam streams on their own network. The project advertises support for all Neptune 4 series models, and lists an Orca Slicer profile set, preconfigured macros for LED control, bed leveling and PID calibration, screws tilt adjustment and axis twist compensation. Firmware retraction and adaptive meshing are already configured in the shipped printer configuration.

There is a second audience consideration. The image is a fork of armbian-mkspi and an Armbian-ZNP-K1 build base, and it ships with the Elegoo services removed, which the project claims avoids Z-axis issues. Removing vendor daemons is the whole point, but it also means the printer behaves unlike a stock unit, and anyone who likes the Elegoo app will find nothing familiar left.

## Klipper v0.13 with a simplified printer.cfg

The heart of the image is Klipper v0.13, installed alongside what the project calls Easy MCU flash. On the Linux side you get moonraker talking to the Klipper host, and a modified printer.cfg described in the feature list as simplified and highly modified. That single file is where most of the value sits for a new owner, because the tedious parts of a Klipper setup, stepper tuning, axis scaling and probe offsets, arrive preconfigured rather than something you derive from a stock config.

Two entries in the repository root show how the work is split. The printer-confs directory holds the printer configuration, and mcu-firmware holds the MCU side, so a change to one does not necessarily mean the other changed with it. The dtb directory carries device tree blobs, which matters because these boards ship with more than one mainboard revision and the correct blob has to be selected at build time.

Other repository entries are img-config, the image configuration area, orca-profiles for the slicer, supported-wifi-adapters as a plain file listing dongles that are known to work, and a root script named OpenNept4une.sh. The README does not describe what that script performs, so treat its contents as something to read before running rather than something to trust blindly. The repo also has a CODE_OF_CONDUCT.md, which signals a community project with governance of some kind rather than a single maintainer's script collection.

## The touchscreen runs through a separate display_connector project

Neptune 4 printers ship with a small screen on the board, and running a generic Linux image on that board leaves the display blank. OpenNept4une handles this with a companion repository, display_connector, which the project maintains separately and points at for its own commit history. The README marks touchscreen support as BETA and calls it more responsive, so the honest reading is that the display path works and is being worked on, but it is not finished.

That split has consequences for anyone assessing maintenance risk. The release artifact you download comes from OpenNept4une, but the display behaviour depends on code that ships separately. The README addresses this by pointing at the dev branches of both OpenNeptune3D/OpenNept4une and OpenNeptune3D/display_connector as the places to check for recent fixes.

A built-in updater in the main Linux image pulls the latest changes directly from the project's various GitHub repositories, which the README describes as a deliberate response to release files that can look outdated. The practical reading is that a release tag is a starting point rather than a frozen state. If you need a reproducible configuration for a shop or a classroom, you would have to pin commits yourself, since the updater is designed to move you forward.

## Getting from a stock printer to a running Fluidd interface

There is no command sequence to reproduce here, because the project does not publish one in the README. Installation is handled by two destinations the README links directly: the releases page for the download and a wiki page labelled Installation. The top of the README presents both as a Download, Installation and Discord Server table, which tells you the project expects you to follow a documented procedure rather than run a one-liner.

The practical path is the one the image implies. You download a release asset, you write the Armbian image to the printer's storage, and the image boots into a Linux system that already contains Klipper, moonraker and the web interfaces. The README gives no flash instructions, no card size requirement and no driver notes, so all of that detail has to come from the wiki.

Once it boots, the interfaces available are Fluidd and mainsail, both of which connect to moonraker and therefore to Klipper. A simple mjpg-streamer webcam configuration script is included for MJPG and YUYV webcams, which is a small convenience that saves hand-editing a stream service for people adding a camera. Temperature monitoring for both the Linux host CPU and the MCU appears inside Fluidd, and the image also configures improved mainboard cooling and fan control. The first real use therefore looks like opening the Fluidd interface from a browser on your network and confirming the printer responds.

## Orca profiles and adaptive meshing arrive already tuned

The Orca Slicer profiles included in the repository are the quiet win for anyone who prints more than the occasional test cube. They sit in the orca-profiles directory, so they are ordinary text or JSON configuration you can copy into your own slicer installation and edit. The project also folds in KAMP, the Klipper Adaptive Meshing and Purging extension, which handles the mesh calculation and purge move around the nozzle. Adaptive meshing is listed as already configured, meaning the purge and probe sequence is part of the shipped printer.cfg.

Most of the remaining preconfiguration has the same character. Screws tilt adjustment and axis twist compensation are configured, so a skewed frame and a warped gantry are handled by the printer rather than by hand. Firmware retraction is configured as well. Bed leveling and PID calibration macros are preconfigured. None of this is exotic; it is the standard set of things a Klipper user assembles over a weekend, packaged so you do not have to.

The trade-off is visibility. A heavily modified printer.cfg is convenient until something behaves oddly, and at that point you are reading a file that somebody else assembled for a board revision you may not have. The repository ships multiple configurations in printer-confs, and the fact that they are kept in a directory rather than a single file suggests variants are expected. Knowing which config matches your mainboard is worth checking early.

## What OpenNept4une will not do for you

Several limits are visible without digging. Touchscreen support is labelled BETA, so a printer whose main appeal is the built-in screen may lose more than it gains. The vendor stack is removed entirely, so Elegoo-specific applications and any expectation of official firmware update paths go with it. The project states that Elegoo Firmware Updates are no longer needed going forward, which is convenient for the operator and means the printer is fully your responsibility afterwards.

Wireless support is honest about its scope. The image supports many USB WiFi adapters, and the repository carries a file named supported-wifi-adapters, but there is no promise that every dongle works. A printer that expects to be reached wirelessly will need an adapter from that list or a wired connection, and the failure mode is likely to be a silent one where the interface loads but the network never comes up.

There is also no documentation of rollback. The README covers features, downloads, the wiki and Discord, but it says nothing about restoring the original Elegoo software, and it does not describe a rescue path for a failed flash. For a printer that cost real money and whose board is the only machine you have, that gap matters. A migration with an irreversible step and no documented way back deserves a plan before it starts.

## Release cadence and what the tags tell you

Three release tags are visible. v0.1.5 was published on 2023-12-13 and carries a kernel and build string of 24.02.0-current-6.1.67. v0.1.6 appeared on 2025-10-30 and was labelled as a pre-release, with a 25.11.0-edge build on kernel 6.16.12. The most recent tag, v0.1.7, was published on 2025-11-22 and uses the same 25.11.0-edge and kernel 6.16.12 combination.

Against that, the last push to the repository was on 2026-10-09, which is well after any of the tags. That gap is the central maintenance fact: the tagged release files lag behind development, and the project answers that by shipping an updater inside the image that pulls from the dev branches. The README says plainly that the latest release file may look outdated while the project is actively maintained and updated regularly.

Licensing is GPL-3.0, with a LICENSE file at the repository root. Because the image bundles and forks components such as armbian-mkspi and the Armbian-ZNP-K1 base image, the GPL obligations of those upstream pieces carry into whatever you redistribute. Nothing here is legal advice, but if you intend to publish your own image on the back of this one, the licence file and the upstream credit list are the two files to read.

## Conclusion

OpenNept4une is a reasonable choice for a Neptune 4 owner who already runs Klipper elsewhere and wants a known-good image with meshing, macros and slicer profiles preconfigured. It is a poor fit for someone who wants the printer to keep working like a stock Elegoo machine, since the vendor services are removed and the touchscreen path is marked BETA. Before flashing, confirm that your exact Neptune 4 variant is listed as supported, read the installation wiki page the project points to, and keep a record of the current firmware, because the README does not document a rollback path.

## FAQ

### What does OpenNept4une replace on an Elegoo Neptune 4 printer?

It replaces the manufacturer's software with a custom Armbian image running Klipper, moonraker, Fluidd, mainsail and kiauh, and the project states that all Elegoo services are removed.

### How do I install OpenNept4une on a Neptune 4?

The README points to the project releases page for the download and to a wiki page for installation steps, and it does not publish the flash procedure in the README itself.

### Is the Neptune 4 touchscreen supported by OpenNept4une?

Touchscreen support is listed as BETA and described as more responsive, and it is handled by a separate display_connector repository that the project maintains alongside the main image.

### Which WiFi adapters work with OpenNept4une?

The image supports many USB WiFi adapters, and the repository includes a file named supported-wifi-adapters listing dongles that are known to work.

## Sources

- [Issues](https://github.com/OpenNeptune3D/OpenNept4une/issues)
- [License: GPL-3.0](https://github.com/OpenNeptune3D/OpenNept4une/blob/main/LICENSE)
- [OpenNeptune3D/OpenNept4une on GitHub](https://github.com/OpenNeptune3D/OpenNept4une)
- [README](https://github.com/OpenNeptune3D/OpenNept4une/blob/main/README.md)
- [Releases](https://github.com/OpenNeptune3D/OpenNept4une/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openneptune3d-opennept4une