Altium Designer + OpenVault

Managing Altium files at scale

Altium Designer projects produce binary files that are hard to version: .SchDoc for schematics, .PcbDoc for PCB layouts, and .PrjPcb for project metadata. Most teams handle this the way they handle mechanical CAD: save files to a shared drive, use naming conventions, and pray no two people edit the same file at the same time.

That approach fails when you need to:

• Trace why a design decision was made two months ago
• Compare a working revision with a failed prototype
• Merge work from multiple engineers without losing anything
• Audit which changes went into each production release
• Work offline and sync later

OpenVault brings Git's version control workflow to Altium files. Store your projects in a Git repository, and OpenVault handles the binary format automatically via Git LFS.

How it works: Altium with Git and Git LFS

OpenVault sits underneath Altium Designer, tracking files as you save them. You work in Altium the same way you always have: open the project, edit schematics, route the layout, save.

When you're ready to preserve a change, you commit it from the command line:

openvault commit -m "Increase trace width on 5V rail to reduce crosstalk"

That commit becomes part of your project history. It includes the message (why), the timestamp (when), and the author (who). Later, another engineer can run:

openvault log

And see the full evolution of the design. They can check out any earlier revision to compare layouts, or understand why a particular decision was made.

When you want to explore a change without affecting main, you branch:

openvault branch add high-speed-variant

Now you have a private space. You can reroute the high-speed signals, add test points, and refine the placement without touching what the rest of the team is working from. When the design is solid, you merge it back, and the full change rolls into main.

If someone else edits the same board file while you're working, OpenVault detects the conflict and shows you both versions. You resolve it by hand because the person who understands the design intent should make the decision. Automatic merging of PCB geometry is unsolved, and a system that silently mangles binary files erodes trust.

File formats and tracking

Altium projects consist of several file types:

Binary files (tracked via Git LFS):

• .SchDoc: Schematic sheets (binary format)
• .PcbDoc: PCB board layout (binary format)
• .PrjPcb: Project configuration (binary format)
• .OutJob: Output batch jobs (binary format)

Text files (tracked in plain Git):

• .txt: NetLists, reports, BOMs
• .net: SPICE netlists
• .pl: Gerber files
• .csv: Component lists (generated or manual)

OpenVault automatically routes the binary files (.SchDoc, .PcbDoc, .PrjPcb) through Git LFS so they don't bloat your repository. Text files live in plain Git where diffs are readable and history is easy to audit.

The key insight is that you commit the whole design at once: schematic, board, output, and any supporting docs. That way the schematic revision always matches the PCB layout that was routed from it. No orphaned netlists. No version skew.

Release traceability and audit

In regulated industries like medical devices and aerospace, you must be able to answer "what changed between release 2.1 and 3.0" with full confidence. With Altium files on a shared drive, that question is archaeology: you dig through old versions, look for git tags if you have them, and piece together what happened.

With OpenVault and Git, release traceability is built in. When you tag a commit with a version:

openvault tag v3.0-production

That tag points to an exact snapshot of every file in the project: schematic, layout, bill of materials, design rules, output settings. Everything. Later, when you need to know what changed, you run:

openvault log v2.1..v3.0

And you get a complete audit trail of every commit between those releases, including who made each change and why. For compliance and design review, that level of clarity is invaluable.