PrusaSlicer ships Windows and macOS binaries, but Linux goes through Flathub alone

Slic3r's lineage shows in the settings, and the compiler floor is C++20

PrusaSlicer started as a fork of Slic3r by Alessandro Ranellucci and the RepRap community, and the project still credits that origin in its own words.

The second structural detail is the compiler assumption. The source states it expects C++20 support across the codebase, and CMake drives the build. The README does not name which compiler releases qualify. The project description itself, naming RepRap, Makerbot and Ultimaker as supported machines, is the broadest statement of hardware coverage the repository offers, and there is no per-model support matrix to check a specific printer against.

Linux has exactly one distribution channel, and it is Flathub

For Linux the README states that PrusaSlicer is currently distributed exclusively through Flathub, at flathub.org/en/apps/com.prusa3d.PrusaSlicer. There is no .deb or .rpm in the project's install instructions, and no distribution packaging directory sits at the top level of the source tree. What a Linux user gets is therefore a Flatpak, which puts your install behind two gates you do not control: whether Flathub is reachable from the machine, and whether the distribution supports the Flatpak runtime.

Windows and macOS are handled differently. Both platforms are offered as direct downloads from the GitHub releases page, with no packaging format specified beyond that. On Linux, an air-gapped machine, a locked-down corporate image, or a policy that forbids Flatpak leaves building from source as the only documented route.

Getting PrusaSlicer means a web download, not a package you can script

The README gives no shell command for installing PrusaSlicer. It names the download on the PrusaSlicer project page as the recommended installation method, offers direct downloads from the GitHub releases page for Windows and macOS only, and points anyone building from source at doc/Build.md. Nothing here can be scripted.

The consequence for an automated pipeline is that you assemble the version list yourself from the GitHub releases page, or you compile. The repository will not tell you which of those two paths the project considers supported for unattended installs. The same gap follows straight into automation: the README states that a command-line interface exists for using PrusaSlicer without the GUI in automation setups, and it names no flag, subcommand, or example for it. If headless slicing is on your critical path, the CLI surface has to come from the binary or the source rather than from the documentation on this page.

PrusaConnect and Printables are the only two integrations named

Two external integrations appear in the feature list, and both are optional: PrusaConnect, the printer management service, and Printables, the model site. The README frames them as workflow simplification rather than as requirements, and the rest of the feature list stands without them. Sending prints to a printer is listed as a separate capability with a wide range of possibilities behind it, so a workflow that avoids the vendor cloud is not blocked by declining either integration.

Three things the README leaves open are the ones to resolve before you depend on this path: where the credentials live, what the slicer does when connect.prusa3d.com is unreachable, and whether an upload is opt-in per project or automatic. For questions that are not bugs, the project keeps a GitHub Discussions page inside this repository covering general discussion and feature requests, with an announcements category for direct communication from the maintainers.

Each bed carries its own settings, so a batch run can slice the wrong one

A PrusaSlicer project can hold multiple beds at once, and the README is explicit that each bed may carry different settings. Several projects can be open in the same session on top of that. This reads as a convenience and it has a cost. Which settings apply depends on which bed is active, so an automation script built on the assumption of one global configuration can produce output for the wrong machine without raising an error.

The README's own list of object edits names paint, cut and arrange, plus "many more" it leaves unnamed. The precision claim above that list runs from settings affecting the whole print down to single-layer adjustments, which is the part that distinguishes this slicer from a one-click converter. Anything beyond those verbs, including the settings the community argues about most, you will have to find in the source tree or in vendor documentation rather than here.

A source build splits its libraries across deps/ and bundled_deps/

Building from source is documented in doc/Build.md, and the technical-stack section tells you what the build is signing you up for. All of PrusaSlicer is C++ with CMake. The slicing backend leans on Clipper by Angus Johnson for polygon boolean operations and offsets, Eigen handles basic types and linear algebra, and wxWidgets provides windows and events across platforms. Most of the interface is a custom OpenGL toolkit built on the Yoga layout engine and Dear ImGui, which is what makes the same windows code run on all three desktop systems.

Two directories at the top level explain how those libraries arrive: deps/ and bundled_deps/, which the README points to for the complete list. The README does not describe how the two folders differ.

3.0 is at alpha12 while 2.9.6 is the newest full release

The tag list says where this project stands. The two newest releases are version_3.0.0-alpha13 and version_2.9.7, both on 2026-11-02, followed by version_3.0.0-alpha12 on 2026-09-21. The newest complete release is version_2.9.7. The last push landed on 2026-11-02, the same day as alpha13 and 2.9.7, so work continues on both lines and the 3.0 line has not been declared stable.

Nothing in the README says what changes for someone moving from 2.9.6 to 3.0, whether saved profiles carry across the major bump, or whether custom start and end G-code hooks keep their behavior. Version.inc sits at the top level of the tree as the version source, and the alpha suffix in the tag names is the only signal you get. Test your own profiles before switching.

A policy check stands between a reporter and the issue tracker

Filing a bug has a gate in front of it. The README says bugs can be reported in the GitHub issue tracker, and to make sure the report complies with the issue tracker policy first. If you are not sure, it says to get in touch through GitHub Discussions before filing, and to file the bug report later once you have more confidence. That ordering is sensible for triage, but it has a side effect: a reproducible defect can sit in Discussions rather than in the tracker, so searching Discussions is worth doing before concluding that a bug is unfixed or unaddressed.

Pull requests go through the contribution guide at .github/CONTRIBUTING.md, which the README points to rather than summarizes. AUTHORS.md at the top level records who contributed. Neither file is described in the README itself, so the review expectations for a pull request have to be read before you write one.

Editorial conclusion

PrusaSlicer fits makers who want per-bed settings, multi-material work, and object-level editing across FDM and mSLA machines, and it fits them best when a Flathub package or a GitHub build is an acceptable way to install. It does not fit a Linux shop that is air-gapped or has banned Flatpak unless it is prepared to build from source, and 3.0 is still an alpha, so anyone standardizing on a stable release should stay on 2.9.7 for now. Verify two things before you commit: that a machine profile exists for your printer, and that your existing 2.9 profiles and custom start and end G-code behave the same way under whichever version you pick.

Frequently asked questions

Official sources

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