UltiMaker Cura: a Python and QML slicer for people who want to change the slicer

What Cura solves, and who ends up maintaining it

A slicer sits between a mesh and a printer. It reads an STL or similar file, decides where the nozzle travels, how fast, how hot, and how much filament to push, then writes G-code the firmware executes. Cura does that with a settings model that is layered rather than flat: a global profile, a per-extruder profile, and per-object overrides can all apply to the same print, and the visible setting list changes depending on which printer and which quality preset is active. That layering is the actual product. The README describes it as a "State-of-the-art slicer app to prepare your 3D models for your 3D printer" with "hundreds of settings & community-managed print profiles".

The audience splits in two. The first group is end users who download a release, pick their machine from a list, and slice. The second group is people who add machine profiles, translate strings, or write plugins, and the README routes each of them to a separate wiki page: one for adding new machine profiles, one for translating Cura, one for plugins and packages. If you are in the second group, the repository is the interesting artifact. If you are in the first, most of what follows is about installation and profile selection, not code.

How the slicing pipeline and the Uranium framework fit together

Cura is a front end. The description states it is a GUI built on top of the Uranium framework, and the repository layout reflects that separation: cura/ holds the application code, cura_app.py is the entry point, plugins/ holds the bundled plugin set, resources/ holds icons, profiles and QML assets, and tests/ holds the test suite. The UI is written in QML on top of PyQt6, which is why the topics list both qml and pyqt6 alongside slicer and gcode.

The build system is the part that surprises people. There is a conanfile.py and a conandata.yml at the top level, a CMakeLists.txt, and a CuraVersion.py.jinja template that generates the version module. Dependencies are resolved through Conan rather than pip, and the README opens with a notice that the project switched to a new remote server for its Conan artifacts, instructing contributors to run a config install command to point Conan at the new remote. That notice is the first thing on the page for a reason: if your Conan configuration still points at the old remote, the dependency step fails before any Python is compiled.

Data flow inside the application is profile-driven. A machine definition selects which settings exist and what their defaults are, a quality profile overrides a subset of those, and per-object or per-extruder changes override again. The G-code is the output of resolving that stack against the mesh. Because the settings live in profile files rather than in code, adding a printer is mostly a data contribution, which is why the README treats machine profiles as a community-maintained surface.

Installing Cura and slicing a first model

The README does not describe a pip install or a package-manager command. For a normal install it points at the releases page, where platform builds are published; the current release line shown in the repository is 5.13.0, with 5.14.0-alpha.0 published ahead of it. Download the build for your platform and run it. There is no documented command-line install path for end users in the README.

If you are building from source on Linux, the README sends you to the Getting Started wiki page rather than repeating the steps, and the repository shows what that build involves: Conan for dependencies, CMake for the build, and a Python entry point. The one command the README does spell out is the Conan remote configuration, because the project moved its artifact server:

conan config install https://github.com/ultimaker/conan-config.git

Run that before anything else. It rewrites your Conan configuration to point at the new remote; without it, dependency resolution pulls from the old location.

Once Cura is running, the first real task is choosing a printer. The README links a wiki page on adding new machine profiles, and the application ships with a machine list that community profiles extend. After selecting your model, the settings panel exposes the profile layers: pick a quality preset, then open the custom settings view to override individual values. The preview screen is where you check the result before writing the file; the repository's own logo image shows Cura open on that preview screen with a large benchy model in the center.

For plugin work, the README points at the plugins and packages wiki page rather than documenting an API in the repository root. Treat that page as the entry point, not the source tree.

Where Cura is the wrong tool

Cura is a desktop GUI application, and nothing in the README suggests it is intended to be embedded as a slicing library in another program. If you need to slice models inside a server process, a CI job, or a web backend, the architecture described here works against you: the pipeline is driven by QML and PyQt6, the dependencies come through Conan, and the settings model is built for interactive editing. There is no documented headless mode in the README.

The second limitation is the build path. Dependency resolution depends on a Conan remote that the project has already moved once, and the README's most prominent instruction exists precisely because that move broke existing setups. Anyone who pins a build to an old Conan configuration will hit a failure that has nothing to do with Cura's code.

The third is profile coverage. Machine definitions and quality profiles are community-managed, so a printer that nobody has contributed a profile for will need one written or adapted before the settings model is useful. The README treats that as a contribution path, not a support guarantee. And if your requirement is a slicer with a stable, versioned scripting API documented in the repository itself, this repository does not present one; the plugin documentation lives on the wiki.

How Cura differs from a scriptable slicer

The clearest comparison is with a slicer designed around a command line and a config file, where the primary interface is a text configuration and the GUI is optional. That model suits automation: you pass a model, a config, and an output path, and you get G-code with no window involved. Cura inverts the priority. The settings are real and extensive, but they are surfaced through a QML interface and a profile hierarchy meant for a person sitting in front of the preview screen.

The practical difference shows up in two places. First, reproducibility: a config-file slicer lets you commit the exact parameters next to the model, while Cura's layered profile model means the effective settings for a print depend on the machine definition, the selected quality profile, and any per-object overrides. Second, extension: Cura's extension mechanism is the plugin and package system documented on the wiki, which runs inside the application. A scriptable slicer's extension mechanism is usually the config file and the shell.

Neither is strictly better. If your workflow is one operator, one printer, and visual verification of every print, Cura's model is faster to work with. If your workflow is a build server producing G-code for many models, the config-file approach fits the surrounding tooling more naturally.

Maintenance, releases and the LGPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-21, one day before this writing, so the codebase is receiving changes. Releases arrive on a regular cadence: 5.13.0 on 2026-05-28, 5.12.1 on 2026-04-13, and an alpha, 5.14.0-alpha.0, published on 2026-06-25. The alpha indicates the project also ships pre-release builds ahead of stable ones, so a pinned version matters if you depend on behavior staying put.

Upgrade cost depends on which path you took. Users of the release binaries replace an application and re-check their profiles. Anyone building from source carries the Conan and CMake toolchain, and the Conan remote change documented at the top of the README is the kind of event that forces a build-configuration update independent of any code change. Budget for that: the dependency layer moves on its own schedule.

Cura is licensed under LGPL-3.0. That is a copyleft licence with a linking exception aimed at libraries, and it carries obligations around distributing modified versions and around the ability to relink. The repository also ships a licenses_thirdparty directory, which lists the other licences bundled into the application. If you plan to redistribute a modified Cura, read the licence text and that third-party list together; this article is not legal advice and does not summarize what those obligations require of you.

Editorial conclusion

Adopt Cura if you need a slicer whose settings tree, machine profiles and plugin surface you can read and modify, or if you maintain a printer definition for a community. Do not adopt it as a library: it is a desktop application, and the README points contributors at a wiki rather than an API. Before committing, check that your printer model has a profile in the machine list, confirm the Python and Qt versions your distribution ships against the build instructions, and decide whether you need the release binary or a source build, because those two paths have very different maintenance costs.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. Ultimaker/Cura on GitHub