atopile: a compiler and declarative language for KiCad circuit boards
Design circuit boards with code! ✨ Get software-like design reuse 🚀, validation, version control and collaboration in hardware; starting with electronics ⚡️
At a glance
- What is it?
- atopile turns electronics design into .ato source files that a compiler solves, validates and pushes into a KiCad layout. It is a real workflow change for engineers who already script their hardware, and a hard sell for anyone who does not want a build step between them and a schematic.
- Who is it for?
- Adopt atopile if your boards are mostly reused modules, parametric part selection and CI-checkable rules, and you are willing to keep KiCad for placement and routing. Do not adopt it if your design is a one-off analog board where the schematic itself is the deliverable, or if you cannot run a build step before layout.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 95 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem atopile targets: hardware that cannot be diffed
A schematic file is a drawing. Two engineers editing the same board produce binary or XML artifacts that merge badly, and the reasoning behind a component choice usually lives in someone's head or in a spreadsheet that drifts from the design. The README frames the goal as writing hardware like software, with reusable modules, equations that capture intent, and automatic parametric picking of discrete components. The unit of work becomes a text file you can review, branch and reuse across products.
The audience is narrower than the tagline suggests. It fits teams that already build several boards from common blocks (a power stage, a microcontroller core, a connector interface) and want those blocks versioned rather than copy-pasted. It also fits people who think in constraints: give me a resistor that satisfies this equation and is in stock. It does not fit an engineer who treats the schematic editor as the primary thinking surface, because in atopile the schematic is downstream of the source.
How the .ato language, compiler and KiCad handoff fit together
The README describes `ato` as a declarative language for electronics with modules, interfaces, units, tolerances and assertions. The compiler, per the same text, solves constraints, picks parts, runs checks, and updates your KiCad layout. So the data flow runs one way: .ato source in, solved design and an updated .kicad_pcb out.
The language constructs matter more than the slogan. Interfaces let a module expose a typed port (say, a power input) instead of a loose bundle of pins, so a module can be swapped without rewiring every net by hand. Units and tolerances mean a value like a resistance or a voltage rating carries its dimension and an acceptable range, which is what makes the assertion layer possible. Assertions are where the design intent becomes machine-checkable: the compiler can fail a build rather than a reviewer noticing a wrong part three weeks later.
Parametric picking is the part with the clearest economic argument. Instead of choosing a specific resistor and re-choosing it when it goes out of stock, you state the requirement and let the compiler select from the registry. That is also the part most exposed to the registry's contents: if a suitable part is not described there, the automation has nothing to pick from.
KiCad remains the layout tool. The README says layout works natively with KiCad and that KiCad is optional to get started, because builds still run and update the .kicad_pcb without it. Placement and routing are not replaced.
Installing atopile and running the first build
The README recommends the editor extension over a manual CLI install. The VS Code/Cursor extension, listed at marketplace.visualstudio.com under the item name atopile.atopile, installs and manages `ato` for you. The README points advanced setups and CLI installs at docs.atopile.io/atopile/guides/install, which is also where the editable installation path for working on atopile itself lives.
The quickstart is four steps. Install the extension, run the command "atopile: Open Example" and pick one, then press the play control in the ato menu bar or run `ato build` from the terminal. Open layout when ready. The README notes the ato menu bar sits in the bottom-left of the VS Code or Cursor window, which is worth knowing because it is not in the usual status bar position people scan first.
For contributors, the repository gives a test command, `pytest -q`, and a worktree helper: `ato dev worktree <suffix>`, then `cd ../atopile_<suffix>`, `source .venv/bin/activate`, `ato --help`. The README states this does a copy-on-write clone of `.venv` plus the Zig cache and output, then rewrites paths, and that it starts an interactive shell in the new worktree by default. Passing `--no-cd` skips the shell handoff. That is a maintenance convenience aimed at people changing the compiler, not at board designers.
Where the toolchain gets in your way
The build step is the first constraint. Every change to intent goes through the compiler before it reaches the layout, so a compiler bug or an unresolved constraint blocks layout work entirely. The README does not describe an escape hatch for editing the PCB directly and merging that back, and it does not claim one.
Windows is listed with WSL recommended. That is a real caveat for teams standardized on native Windows tooling, since it means the supported path runs through a Linux environment.
The examples in the README span a smart speaker, a multi-channel DSP, a battery cell simulator and a display driver. Those are board-level products with repeated channel structures and mixed analog and digital content, which is exactly the shape parametric selection and interface reuse handle well. A single-board design with no repeated blocks and no reuse ambitions gets the syntax cost without the payoff.
Version churn is visible in the release list: v0.14.2, v0.14.3 and v0.14.1004 all within about a day in February 2026. A language and compiler moving that fast means the .ato syntax in a tutorial or an example repository may not match the compiler you installed. The README does not state a stability guarantee for the language, so treat example code as version-coupled until you confirm otherwise.
atopile against a plain KiCad project
The honest alternative is KiCad alone, which is free, mature, and requires no build step. In that workflow the schematic is the source of truth, part numbers live in symbol fields, and design rules are checked by the ERC/DRC passes inside the editor. Nothing is compiled.
The difference is where the intent lives. In KiCad, a rule like "this divider must produce 1.8 V from a 3.3 V rail" exists as a comment or as a value you verify by reading. In atopile, per the README, that intent is expressed as units, tolerances and assertions, and the compiler runs the checks. The same applies to reuse: KiCad has hierarchical sheets and snippets, but they are copied into a project, whereas atopile modules are pulled from a package registry at packages.atopile.io and referenced by name.
The trade is straightforward. KiCad gives immediate, direct manipulation of the design and no toolchain risk. atopile gives you a reviewable text diff, automated checking and part selection, at the cost of a compiler dependency and a language you have to learn. If your team's bottleneck is not reuse or verification, KiCad alone is the lower-risk choice.
Licence, releases and the cost of staying current
atopile is MIT licensed, and the README points to the LICENSE file in the repository. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are retained. That covers the toolchain itself. It does not automatically cover the contents of the package registry or third-party modules you pull in, and the README does not describe the licence terms of registry packages. Check the licence of each module you depend on before shipping a board built from it. This is a description of the licence text, not legal advice.
Upgrade cost is the part the README is quiet about. There is no stated deprecation policy, no long-term support branch and no migration guide in the material provided. Given three releases inside roughly 24 hours in February 2026, the practical assumption is that pinning a version and reading the release notes before moving is cheaper than tracking the default branch. The `ato dev worktree` command exists to make working on the compiler itself fast, which tells you the maintainers expect contributors to run many builds; it does not reduce the cost for a design team that has to re-verify a board after a compiler upgrade.
Commercial support is available at hi@atopile.io per the README, and the Discord has a help channel. Both are the documented routes when the compiler does something the assertions did not anticipate.
Editorial conclusion
Adopt atopile if your boards are mostly reused modules, parametric part selection and CI-checkable rules, and you are willing to keep KiCad for placement and routing. Do not adopt it if your design is a one-off analog board where the schematic itself is the deliverable, or if you cannot run a build step before layout. Verify first that the compiler version you install matches the .ato syntax in the examples you copy, that the packages you depend on exist in the registry at packages.atopile.io, and that `ato build` produces the BOM and fabrication outputs your manufacturer accepts.
Community notes