If you come from software, you already know CI/CD — continuous integration and continuous delivery, the practice of automatically building and testing your code every time you change it. CI/CD for PCB design is the same idea applied to hardware: every time you change your board, a pipeline automatically regenerates your manufacturing outputs and runs your design checks, so what you can hand to a fab is always current.
Short answer: CI/CD for PCB means connecting your KiCad project to an automated pipeline that, on every change, re-exports Gerbers, BOM, and placement files, runs DRC and ERC as pass/fail gates, produces PDFs and 3D renders, and publishes a clean release package — no manual exporting, no stale files.
What CI/CD means for hardware
In software, you commit code and an automated system compiles it, runs the tests, and — if everything passes — ships it. Nobody rebuilds the app by hand and nobody emails a zip of the binary around.
Hardware has an equivalent set of "build" and "test" steps, they're just usually done manually. The "build" is exporting your manufacturing files. The "test" is running design rule checks (DRC) and electrical rule checks (ERC). The "artifact" is the package you send to your board house.
CI/CD for PCB simply automates that loop. You change the schematic or layout, and a pipeline does the rest — the same way a software pipeline reacts to a commit. The board is the source; the outputs are generated, never hand-assembled.
What you actually automate
A PCB pipeline is not magic. It's a defined sequence of steps that a machine runs for you every time your design changes:
- Regenerate the manufacturing outputs — Gerbers, drill files, the bill of materials (BOM), and the component placement / pick-and-place file (CPL). These are the files a fab and assembler need, and they should always reflect the latest design.
- Run the checks as gates — DRC and ERC run automatically. If a rule fails, the pipeline flags it. You catch the clearance violation or the unconnected net when you introduce it, not the day before you order boards.
- Produce human-readable outputs — schematic PDFs, fabrication drawings, and 3D renders or STEP models for mechanical review. Great for design reviews and for anyone who doesn't have KiCad open.
- Publish a release package — a single, consistent set of artifacts you (or a client, or an assembler) can download, knowing every file came from the same revision.
The key shift is that these outputs stop being things you remember to do and become things that just happen.
Manual workflow vs CI/CD workflow
Here's the same job, done two ways:
| Step | Manual workflow | CI/CD workflow |
|---|---|---|
| Export Gerbers & drill | Open GUI, plot by hand each revision | Regenerated automatically on every change |
| BOM | Export separately, hope it matches | Generated from the same revision, every time |
| Placement / CPL | Manual export, easy to forget | Always produced alongside the rest |
| DRC / ERC | Run when you remember to | Run automatically as a pass/fail gate |
| 3D / PDFs | Optional, often skipped | Generated for every build |
| Release package | Zip files by hand, name it final_v2 |
One consistent, reproducible artifact set |
| Risk of stale files | High — sets drift out of sync | Low — everything comes from one revision |
The manual column isn't wrong — it's how most teams work. It's just slow, easy to get wrong, and it produces the classic failure mode where the Gerbers are from one revision and the BOM is from another.
The benefits, concretely
- Always-current outputs. Your manufacturing package reflects the design as it is right now, not as it was the last time someone remembered to export.
- Catch regressions early. Because DRC and ERC run on every change, a mistake surfaces immediately, while the context is fresh and the fix is cheap — not after a fab rejects the board.
- Reproducibility. Every artifact traces back to a specific revision of the design. If you need to rebuild the exact package you sent three months ago, you can.
- Painless handoff. Handing a board to a colleague, a client, or an assembler becomes "here's the release" instead of a scramble to re-export and double-check that everything matches.
If you've ever fought the final-v2 zip problem, CI/CD is the structural fix: there is no "final version" to track by hand, because the outputs are generated on demand from the design itself.
How this maps onto KiCad
None of this requires leaving KiCad or buying a premium suite. KiCad ships kicad-cli, its official command-line tool, and that's the engine that makes a pipeline possible.
kicad-cli can, without ever opening the GUI:
- export Gerbers and drill files,
- generate a BOM,
- export the component placement (CPL) file,
- render schematic and board PDFs,
- export 3D models (STEP),
- and run DRC and ERC headlessly, producing machine-readable reports.
Because it runs from the command line, it can run on a server, triggered automatically. That's the whole trick: a pipeline is just kicad-cli invoked in the right order, on the right event, every time — with its DRC/ERC results used as gates.
Because KiCad's files are plain text, they also pair naturally with Git version control, which gives the pipeline a clean "on every change" trigger to react to.
What a minimal pipeline looks like
Conceptually, the smallest useful PCB pipeline is short:
- Trigger: a change lands in your project.
- Check: run ERC and DRC. If they fail, stop and report.
- Build: run
kicad-clito export Gerbers, drill, BOM, and CPL. - Render: produce PDFs and a 3D model.
- Publish: collect everything into one downloadable release.
That's it. Everything else — manufacturer-specific formats, assembly checks, quoting — layers on top of that same spine. (If you've ever shipped a board and discovered a missing manufacturing file, a pipeline is what guarantees the package is complete every time.)
Where GoForFab fits
Building and hosting this pipeline yourself is entirely doable — kicad-cli is free and well documented. But it's also a chunk of infrastructure to set up and babysit: a server, the KiCad toolchain, output storage, and the glue that ties it to your project.
That's exactly what GoForFab is: CI/CD for KiCad, without a pipeline to build yourself. Connect a project and every change regenerates the full manufacturing package — Gerbers, BOM, CPL, DRC/ERC reports, PDFs, and 3D renders — always current, always reproducible, ready to download or order. It's free forever to get started, so you can see always-current outputs on your own board before writing a single line of pipeline config.
Whether you build it yourself or let GoForFab handle it, the principle is the same one software teams settled years ago: don't assemble your outputs by hand. Let the machine do it, every time, and check the design while it's at it.