Version-control slicer profiles across printers

Slicer profiles are small text files that change often and matter a lot, which is exactly the shape of thing Git is good at. Put the slicer’s user preset directory in a repository, commit when you change something deliberately, and the “what did I change before this started failing” question becomes a diff instead of an argument.

The part Git cannot answer is which profile actually produced a given print, because the moment you edit a preset, the version that made last month’s good part is gone from the slicer. That answer lives in the G-code itself, and a library that parses those headers keeps it after the fact.

Put the presets in a repository

OrcaSlicer keeps user presets as JSON under its configuration directory, split into filament, machine, and process folders per user profile. Find it from Help > Show Configuration Folder rather than guessing the path, since it differs across Windows, macOS, and Linux. PrusaSlicer and Bambu Studio follow the same pattern with their own formats and directories.

Initialize a repository in the user folder rather than the whole configuration directory. The parent holds caches, logs, downloaded system profiles, and window state, none of which you want in a diff. Commit the presets, add a .gitignore for anything that changes on every launch, and push it somewhere your other machines can reach.

Two habits make the history readable. Close the slicer before committing, because it rewrites preset files on exit and you will otherwise commit half-saved state. And commit one intentional change at a time: “PETG process, 0.6 nozzle, slower first layer” is a message that helps in six months, while “profiles” is not.

The whole setup is four commands once you have the folder open:

cd "/path/to/slicer-config/user"   # Help > Show Configuration Folder opens it
printf '*.log\n*.bak\n.cache/\n' > .gitignore
git init && git add . && git commit -m "baseline presets"

Keeping several machines in sync

The mechanics are ordinary Git, with one wrinkle: the slicer owns those files at runtime and will happily overwrite what you pulled.

The workflow that survives is to treat one machine as the place you edit profiles, commit there, and pull elsewhere with the slicer closed. If you edit on two machines in the same week, expect conflicts in JSON that is machine-generated and awkward to merge by hand. Resolving them by picking one side wholesale is usually right, since a half-merged preset is worse than either version.

Printer-specific settings are the other trap. A machine profile that encodes a bed size, a nozzle, or start G-code with a specific macro name is not portable to a different printer, so keep those as separate presets rather than one profile you keep editing. The shared thing is usually the process and filament settings, not the machine.

Export bundles as checkpoints, not as the sync mechanism

Every slicer in this family can hand you its presets as a single file. PrusaSlicer calls it a configuration snapshot, and its configuration snapshots article covers both saving one and restoring it later. OrcaSlicer’s user profiles wiki page documents the same export for its preset folders. A bundle taken before a round of calibration changes is a cheap rollback point, and it is the easiest way to move a complete setup to a brand-new machine.

As a routine sync mechanism, though, bundles age badly. They are opaque archives, so there is no diff and no per-preset history, and restoring one overwrites every preset in it rather than just the one you meant to touch. Keep the Git history as the real record and treat bundles as checkpoints you name by hand.

Sync tools, and what they cost you

Syncthing or a plain rsync job can keep the preset folder identical on every machine without anyone running Git commands. For a single user with one editing machine, that is a perfectly good arrangement, and Syncthing’s own docs describe what happens when it is not: two machines editing the same file between syncs both keep their version, renamed into sync-conflict copies, and a person reconciles them by hand. The folder stays consistent; the intent behind the change does not survive, and nothing tells you what the presets looked like last month.

If profiles matter enough to keep in sync across machines, they usually matter enough to commit. The sync tool and the Git history are not mutually exclusive: sync the folder for convenience, and let the one editing machine carry the repository that remembers why each change happened. For a deeper look at that tradeoff on model files rather than presets, syncing STL files between a PC and a NAS covers the same choice with mounts, rsync, and Syncthing.

What the library adds that Git cannot

A repository tracks the profile as it is today, and every commit tells you what it looked like on a date. What it does not tell you is which preset produced the file that printed well, because the G-code that came out of it lives somewhere else entirely.

PrintStash parses each uploaded slice and stores the settings the slicer wrote into the header: slicer name and version, printer model, nozzle diameter, layer height and first layer height, infill percentage, wall loops, top and bottom shell layers, whether supports were on, hotend and bed temperatures, estimated time, filament weight, length and cost, and the material type and brand. Those values are frozen at the moment of the slice. Editing the preset afterwards does not change them.

That is the record that makes a good print reproducible. Compare the revision that worked against the one that did not and the difference shows the settings that actually changed, which is faster than reading two JSON files and hoping you spot the line that matters. And a revision marked known good is a claim about specific values, not about a profile name that has since been edited three times.

One side effect is worth knowing: the first time a file names a printer preset or a material, PrintStash creates a local printer or filament profile from it, filling in the model, nozzle diameter, and, when the slicer wrote both a total filament cost and a weight, an inferred cost per kilogram. Those local profiles are for costing and filtering. They are not copies of your slicer presets and cannot be exported back into the slicer.

The honest division of labor

Git versions the profiles. The library versions the output and records what each slice was made with. Neither replaces the other, and trying to make one do both ends badly: a library is not a config manager, and a repository of preset files cannot tell you that the 0.16 process printed clean on the Voron and warped on the Ender.

A workable routine looks like this:

1. Keep the slicer’s user preset folder in Git, one commit per deliberate change.
2. Edit profiles on one machine, pull to the others with the slicer closed.
3. Let each export land in the library with its parsed settings, by hand or through the OrcaSlicer hook.
4. Label the revision with the intent behind the profile change, since the parser records what changed and never why.
5. When a print comes out right, mark the revision known good. That freezes the settings that produced it, independent of what the preset says today.

Questions that come up

Can PrintStash store or version my slicer profiles?

No, and it is not trying to. PrintStash stores the settings that appear inside each sliced file, not the preset files themselves, so there is nothing to check out, diff, or restore into your slicer. The local printer and filament profiles it creates from parsed metadata exist for cost calculation and filtering, and they hold a handful of fields such as printer model, nozzle diameter, material type, and cost per kilogram. For versioning the actual presets, use Git on the slicer’s user configuration folder.

Where are OrcaSlicer’s user presets stored?

Under the OrcaSlicer configuration directory, in a user folder containing per-profile filament, machine, and process subfolders of JSON files. The reliable way to find it on any platform is Help > Show Configuration Folder inside OrcaSlicer, since the path differs between Windows, macOS, and Linux. System presets live alongside them in a separate folder and are replaced on update, so version the user folder and leave the rest alone.

How do I know which profile version produced a good print?

Read it off the slice rather than the profile. The settings are written into the G-code header, parsed on upload, and stored against that revision, so a revision marked known good carries the layer height, nozzle, temperatures, infill, wall count, and material it was actually made with. Comparing two revisions shows the differences directly. This is the only reliable answer once the preset has been edited, because the slicer keeps no history of its own.

Is Git a good fit for G-code as well?

No. Presets are small text files that change occasionally, which suits Git. G-code is 10 to 30 MB per slice, changes completely every time, and diffs into thousands of meaningless coordinate lines. git-lfs fixes the size and removes the diff that was the reason to use Git in the first place. Keep the inputs in version control and let a library handle the outputs, which is covered in tracking G-code revisions. If you would rather regenerate a slice than store it, versioning G-code like software covers the build-system approach, where the pinned slicer replaces the archived file.

What about profiles for printers that are not identical?

Keep them as separate machine presets rather than one preset you keep adjusting. Bed size, nozzle diameter, start and end G-code, and macro names are machine facts, and a profile that mixes them with process settings stops being shareable. Process and filament presets are the portable part, and they are what benefits most from being in one repository across machines.

Should I use Syncthing instead of Git for presets?

For one person editing on one machine, yes, it is simpler and there is nothing to learn. The cost appears the day two machines edit the same preset between syncs: Syncthing keeps both versions as renamed conflict copies and a person reconciles them by hand, and there is no history to fall back on when a change from last month needs undoing. If presets matter enough to sync across machines, a Git repository on the editing machine alongside the sync gives you the history for free.

Sources

• OrcaSlicer user profiles for how user presets are organized, and the in-app Help > Show Configuration Folder for the platform-specific path. Checked August 12, 2026.
• PrusaSlicer configuration snapshots for exporting and restoring a full preset set as one bundle. Checked August 22, 2026.
• Syncthing docs on conflicting changes for what happens when two machines edit the same file between syncs. Checked August 22, 2026.
• PrintStash user guide for the metadata parsed out of each slice and where it appears on a model.

If the goal is reproducible results rather than tidy configuration, one model, many G-codes covers the outcome side, and automatically organizing a library covers what else the parsed metadata does once it is stored.