Every KiCad user has done the ritual: finish a revision, open the plot dialog, tick the layers, generate Gerbers, generate drill files, export the BOM, export the STEP model, run DRC, zip it all up. Then do it again next revision and hope nothing drifted. Jobsets exist to kill that ritual.
Short answer: a jobset is a saved pipeline of output jobs you define once and re-run with one action — from the GUI or kicad-cli. Introduced in KiCad 9 and refined in KiCad 10, it's the native way to make your releases repeatable.
What a jobset actually is
A jobset is a reusable file (.kicad_jobset) containing an ordered list of jobs. Each job is one output action, for example:
- Plot Gerbers for a chosen set of layers
- Export drill files
- Export a BOM (with your chosen fields)
- Export a STEP or GLB 3D model
- Plot a PDF (schematic, fab layers, assembly drawing)
- Run DRC or ERC and emit a report
You configure each job once. From then on, "release the outputs" is a single action instead of a dozen dialogs — and because the definition lives in a file, it's shareable and reviewable alongside the design.
Why it makes releasing easier
The value isn't saving clicks — it's removing drift. When outputs are generated by a saved pipeline, every release is produced the same way. No more "which revision were these Gerbers from?" or a BOM that doesn't match the board. It's the same discipline behind a real hardware release process: an immutable, reproducible set of artifacts rather than a hand-assembled zip.
In KiCad 10, a jobset opens in its own tab in the project manager — jobs listed in the middle, destinations on the right, including a destination that writes the outputs to a folder. So "how this project gets released" is now something you can see and manage, not tribal knowledge in someone's head.
Setting one up
- In the project manager, create a new jobset.
- Add jobs for each output you ship — Gerbers, drill, BOM, CPL/position, STEP, DRC/ERC reports. (See exporting Gerbers and the BOM + LCSC field for the settings that matter.)
- Set a destination folder.
- Run the jobset — from the GUI, or headlessly with
kicad-clipointed at the.kicad_jobsetfile so it fits into scripts.
That last point is the important one: because a jobset runs from kicad-cli, it drops straight into automation.
Where jobsets stop
Here's the honest boundary. A jobset is a saved pipeline — but you still have to run it. It doesn't fire on every commit, it doesn't store history, and it doesn't give a teammate or client a link to the current outputs. It's a better manual step, not a hands-off system.
| Manual export | Jobset | CI (runs the jobset for you) | |
|---|---|---|---|
| Repeatable definition | ❌ | ✅ | ✅ |
| One action to run | ❌ | ✅ | ✅ |
| Runs automatically on every change | ❌ | ❌ | ✅ |
| Stored, versioned, shareable results | ❌ | ❌ | ✅ |
From jobset to continuous integration
Crossing that last column is exactly the CI/CD-for-PCB idea. Define your outputs — in a jobset, or let the platform handle the equivalent — then have something run it on every push, keep the results, and hand you a shareable dashboard.
That's what GoForFab does: connect a KiCad project and every push regenerates the full manufacturing package via kicad-cli — Gerbers, BOM, CPL, DRC/ERC reports, 3D renders — stored and shareable, with nothing to run by hand. Jobsets make your outputs repeatable; CI makes them automatic. Free forever.
Jobsets were contributed by Mark Roszko and shipped in KiCad 9. Source: KiCad 9.0.0 release announcement.