OrcaSlicer has a plugin system now. Not another post-processing script box, but an actual plugin architecture with an embedded Python interpreter, an install dialog, a cloud plugin browser, and per-feature enable checkboxes. The documentation went live on the project’s official wiki, and the feature page is blunt about where things stand: it works in nightly builds, or in any release after 2.4.2.
2.4.2 is the current stable release. So if you grabbed OrcaSlicer from the releases page and have never touched a nightly, you do not have this yet.
That gap matters more than it sounds. I will come back to it. Worth saying up front, though: OrcaSlicer is already the slicer a lot of people pick precisely because its calibration tooling ships in the box, so an extension point is a real change in direction for it.
What a plugin can actually do
A plugin is a folder holding one entry file. Either a single .py with its metadata in a PEP 723 comment block, or a .whl wheel that carries its metadata in the usual place. What the plugin can do depends on which capabilities it registers, and there are three types so far.
Script capabilities run only when you ask them to. Open File > Plugins, expand the plugin row, find the script, click Run. Nothing fires on its own. There is also an Actions Speed Dial that works as a quick launcher for these.
Slicing pipeline capabilities are where it gets interesting. They hook into the slicing workflow at selected points. At the psGCodePostProcess step a plugin receives the working G-code file, after the classic post-processing scripts have already had their turn. Earlier steps hand it the live slicing context instead, which means plugin code can inspect or modify geometry before it ever becomes G-code. OrcaSlicer labels this capability experimental and aimed at plugin developers and testers, with a warning attached in the docs: these plugins can change generated geometry or G-code, so test anything you did not write yourself before you run a real print through it.
Printer connection capabilities add new ways for OrcaSlicer to talk to a machine. The wiki says the printer agent workflow is still in progress, so I would not build a workflow around it yet.
Installing one
Two routes. The Plugins window has a split Browse plugins button: the main action opens the OrcaCloud plugin browser, the dropdown gives you Install local plugin for side-loading a file off your own disk.
Either way, a freshly installed plugin shows up Inactive. You tick the Activate checkbox to turn it on, and each capability inside it has its own checkbox too, so you can enable a plugin’s script and leave its slicing pipeline hook switched off. Configuration lives in a Config tab, as JSON by default, unless the plugin author supplied a custom page. Presets can override that configuration per preset.
The security notes are worth reading twice
Here is the part I keep coming back to.
OrcaSlicer runs plugins through a CPython audit hook, which sounds reassuring until you read what it actually covers. The project’s own documentation does not oversell it. The audit page opens by calling the current version “intentionally a narrow, low-risk first version, not a complete sandbox,” and the architecture overview describes the whole thing as groundwork. Further down, under Limitations, it says plainly: do not treat it as a hardened sandbox.
The specifics back that up. Today the hook enforces exactly one rule, and only while a plugin call is running: file writes have to land inside an allow-list, which currently contains one directory, OrcaSlicer’s own data folder. G-code post-processing plugins also get temporary write access to the folder holding the current G-code file, and only for the length of that call.
What is not covered is a longer list. Only the open event is checked, so subprocess spawning, os.system, sockets, and ctypes all pass through untouched. Deleting or renaming a file raises a different audit event that nothing handles yet, so a plugin can remove or move files outside the allowed folder without tripping anything. Low-level opens that pass a byte string or a file descriptor instead of a text path fail the parser and get waved through. The docs list every one of these gaps themselves, which I respect, and which is also exactly why you should read them before installing anything.
The user-facing wiki page puts it in one line: only install plugins from sources you trust, because plugins can interact with your files and your print workflow. That is not boilerplate here. It is accurate.
The part that will bite people first
Presets now remember the plugins they use.
When a print process, printer, or filament preset points at a plugin capability, the preset also stores a full reference back to that plugin, including a cloud identifier if it came from OrcaCloud. Copy that preset to another machine, or hand a project file to someone else, and OrcaSlicer checks those references when you go to slice.
If it cannot resolve one, you get a notification you cannot dismiss, and the Slice button stays blocked. There is no slice anyway option. You either install the missing plugin, activate it if it is present but switched off, or change the setting that pulls it in.
For a cloud plugin the notification offers an Install Plugins action that subscribes, downloads, and enables it in one step. For a local plugin with no cloud identifier, all it can do is open a browser search on the OrcaCloud plugin page and hope. Something to keep in mind before you start sharing profiles that lean on a side-loaded plugin.
Should you go get a nightly
If you print things, no. Wait for a stable release. Nightly builds are nightly builds, the slicing pipeline hook is explicitly experimental, and the printer agent side is unfinished. The tuning that actually improves your prints today, like getting pressure advance dialed in, needs none of this.
If you write tooling, this is the first time OrcaSlicer has offered a real extension point instead of a shell command in the post-processing box, and the API documentation is already fairly complete. That is a reasonable reason to pull a nightly and poke at it on a machine you do not care about.
For everyone else, the useful takeaway is smaller and arrives later: at some point after 2.4.2, a slicer that a lot of people run will start accepting third-party code with a security boundary its own authors describe as unfinished. Worth knowing before the first plugin someone links you on Reddit looks too good to skip.
Sources
All details above come from OrcaSlicer’s official wiki: the Plugins getting started page, Plugin Types, Plugin System Overview, and Plugin Audit Hook. Version status was checked against the wiki’s releases index on August 8, 2026.