preFlight replaced the Slic3r engine it was forked from and kept the profile import

A fork that retired its own upstream engine

preFlight is described as an advanced 3D printing slicer, and the project page opens with the line: Pilot, You Are Cleared for Launch.

The interesting sentence is the one about what it grew into. What began as a fork of PrusaSlicer has quickly grown into something completely unique. Slic3r, the legacy 15 plus year old code at its core, has been retired and replaced by Luminary, described as a ground-up reimagining of the engine. The UI layer is now DSKY, and the entire dependency stack underneath has been modernized.

So the lineage is two forks deep. preFlight descends from PrusaSlicer, which descends from Slic3r, and the project credits Slic3r to Alessandro Ranellucci and the RepRap community. What the fork inherited was the application shell and the profile formats, and what it replaced was the part that actually did the slicing.

That is a significant engineering claim and it is the reason to look at the tool at all. Slic3r was the ancestor of a great many slicers, and rewriting its core is not something a small team does for fun. The community discussion happens on GitHub Discussions under a preflight-features category, and on the Duet3D forum, which tells you the audience is people who print for a living rather than people who print occasionally.

Profile imports are the feature people come for

The documentation is direct about the practical entry point: preFlight natively imports PrusaSlicer, SuperSlicer and now OrcaSlicer profile bundles, so you can be up and running in minutes.

This is the clearest difference in approach between preFlight and the slicers it replaces. The hard part of switching slicers is not the modelling, it is the profiles. A tuned profile carries layer heights, print temperatures, retraction settings, seam placement and support strategy for a specific printer and filament, and re-deriving those by hand is a slow, error-prone job.

Importing the profile bundle means the settings come with the tool. The documentation notes the OrcaSlicer import in the project features, which suggests each of the three is treated as a first-class import path rather than a partial compatibility layer.

The limit worth knowing is that the documentation names three formats. It does not say that every configuration option of those bundles round trips perfectly, and it does not promise that a profile will behave identically in preFlight's engine than it did in the tool it came from. Slicing behaviour is where engines differ, and the project is careful to describe the import as the feature rather than as equivalence.

Windows, macOS, Linux and a Raspberry Pi package

The requirements section covers four platforms with a downloadable artefact for each.

For Windows, you download the portable zip from GitHub Releases and extract it, with builds available for x64 and ARM64. It requires the Microsoft Visual C++ Redistributable, and the documentation tells you to install that first if preFlight will not launch.

For macOS, you download the DMG. It requires macOS 11.0 or later, that is Big Sur or later, and it is Apple Silicon only, with all builds signed and notarized by Apple.

For Linux, you download the AppImage, make it executable with chmod +x and run it, with no installation required.

For Raspberry Pi, the target is an RPi 5 running 64-bit Raspberry Pi OS, Bookworm or Trixie, and the artefact is the aarch64 .deb package from GitHub Releases.

The Raspberry Pi support is the one that stands out for the platform list, because a Pi 5 running a desktop slicer is a plausible way to run a print farm's slicing locally. The four-platform spread, with a portable zip, a notarized DMG, an AppImage and a .deb, also means there is no install script to trust, which fits the security posture the project takes in the next section.

Signed binaries and a 3MF extraction story

The security section is unusually specific, and it reads like a response to a real problem rather than boilerplate.

The guidance is to only download preFlight binaries directly from the GitHub Releases page, because the project does not distribute preFlight through third-party mirror sites. All official Windows binaries are digitally signed by oozeBot, LLC using an Organization Validation code signing certificate, and the verification procedure is given: right-click the .exe, select Properties, navigate to the Digital Signatures tab, and ensure the Name of signer is explicitly listed as oozeBot, LLC.

The safety rule follows: if you receive a Windows protected your PC SmartScreen warning on a file that is not signed by oozeBot, LLC, do not run it and report the issue immediately. For macOS, all official DMGs are signed with an Apple Developer ID certificate and notarized by Apple, and if Gatekeeper warns that the app is from an unidentified developer, the DMG is not an official release.

The 3MF item is the most technical. Post-process scripts embedded in third-party 3MF files are suppressed on import, and the documentation names the CVE, CVE-2023-47268. All 3MF extraction uses in-memory buffers, so preFlight is not affected by Zip Slip path traversal vulnerabilities.

That is a genuine design decision, not a configuration. A 3MF file is a zip archive that can carry a post-process script, and a slicer that executes it would be running code from a downloaded model file. Suppressing the script removes that path entirely.

One build system, with Windows wrappers around it

The build documentation describes a unified build system across all platforms, with Windows using .bat wrappers that set up the MSVC environment and then delegate to the same underlying scripts.

On Windows, the requirement is Visual Studio 2026, and the documentation says explicitly that VS 2022 is not supported. The scripts are short.

# Build dependencies (first time only)
build_deps.bat

# Build release
build.bat

# Build debug (for development)
build.bat -debug

On Linux and macOS the same three steps exist with shell scripts, plus the macOS prerequisites installed with brew.

# Prerequisites (macOS only)
brew install cmake ninja pkg-config

# Build dependencies (first time only)
./build_deps.sh

# Build release
./build.sh

# Build debug (for development)
./build.sh -debug

The build options table lists the flags: -deps to build dependencies as an alternative to running build_deps separately, -debug to build with debug symbols using RelWithDebInfo, -clean to remove the build directory and rebuild, -config to run only the CMake configure step, -flush to force resource recompilation for icons and splash on Windows, -jobs N for parallel build jobs with auto-detection as the default, and -arch A as an architecture override for macOS with arm64 and x86_64.

The repository layout backs this up: a CMakeLists.txt and CMakePresets.json at the root, a cmake/ directory, bundled_deps/ and deps/ directories for dependencies, build-utils/, a build_stubs.py script, and version.inc holding the version.

The AGPL question for a slicer that people redistribute

preFlight is licensed under the GNU Affero General Public License, version 3, with details in the LICENSE file. The attribution is stated in the same section: preFlight is based on PrusaSlicer by Prusa Research, which is based on Slic3r by Alessandro Ranellucci and the RepRap community.

For a desktop application that most people download and run, AGPL is a licensing choice with limited practical effect. It becomes a live question for anyone who embeds preFlight, modifies it, or offers it as a service, and for anyone who ships it in a commercial product. The documentation does not discuss that, so anyone in that position needs to read the licence text and make their own call rather than rely on the project page.

What the licence does make clear is the lineage. Slic3r came from the RepRap community and Alessandro Ranellucci, PrusaSlicer came from Prusa Research, and the fork chain is documented in the same paragraph as the licence itself. That history matters for a slicer, because the profile formats and the print settings vocabulary are inherited from that lineage, and the import feature depends on it.

The repository also carries a CHANGELOG.md, and the project is distributed under the name oozeBot, LLC for signing purposes, with support by email at [email protected].

Where a different slicer is the better choice

The honest comparison is with the tools preFlight imports from, and the difference in approach is about where the trust sits.

PrusaSlicer, SuperSlicer and OrcaSlicer are established slicers with their own communities, their own hardware profiles and their own support channels. If your printer is a Prusa or a well supported machine, the vendor's own slicer is the one whose behaviour is tuned for that printer, and preFlight is the import target rather than the source of truth.

preFlight's case is that the core was rewritten. A modern engine on a 64 bit architecture is the reason to try it, and the README points at the 64 bit architecture feature page for the Luminary and DSKY details. For someone whose current slicer feels slow, or who wants a different set of import sources in one application, that is a real reason. For everyone else, it is a new tool with a new set of quirks, and the maturity of the rewriting is the thing to judge.

Two limits are worth stating plainly. The documentation covers installs, builds, imports, signing and support, and it does not describe compatibility with specific printer firmware, nor does it list the profile features that are not carried over from an imported bundle. It also does not mention a headless or command line mode for slicing, so anyone who wants to slice on a server would have to look for that elsewhere.

Editorial conclusion

preFlight fits a maker who wants the profile ecosystem of the Prusa and Orca slicers without running those applications, and who is willing to accept a tool whose upstream lineage is a fork rather than a first release. It does not fit a team that cannot accept AGPL terms, and it does not fit a contributor on a toolchain other than Visual Studio 2026 for Windows builds. Before adopting it, download from the project's own GitHub Releases rather than a mirror, check the Windows binary's Digital Signatures tab shows oozeBot, LLC, and confirm the profile import path you rely on is one of the three named bundles rather than a format you expected to be supported.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. oozebot/preFlight on GitHub
3. Project website
4. README
5. Releases