Open almost any engineering shared drive and you'll find the same folder:
Bracket_v2.step
Bracket_v3.step
Bracket_v3_FINAL.step
Bracket_v3_FINAL_revised.step
Bracket_v3_FINAL_revised_JK.step
Everyone knows this is broken. Nobody is quite sure which file is current, who changed what, or why. When two engineers edit at the same time, one person's work quietly disappears. When an auditor asks for the change history, the folder of filenames is all there is to show.
Saving a file creates a snapshot. Versioning keeps every snapshot: every change, who made it, when, and why. It lets you move forward without the fear of losing what came before.
Software teams solved this two decades ago with Git. Engineering teams have version control too. OpenVault is the tool they should have had all along.
It's worth being precise about what's actually wrong, because "engineering has no version control" is a myth. It does. The tools are called PDM and PLM, and they're everywhere. SolidWorks PDM, Windchill, Teamcenter, and the rest. They check files in and out, they keep revision history, they enforce permissions. The problem goes deeper than existence. These tools are miserable to use.
They're miserable because of how they were built. PDM and PLM grew up as enterprise software, and they carry every habit of that world: a central server somebody has to administer, per-seat licenses somebody has to negotiate, vaults that lock you out the moment the network hiccups, and a check-out model that turns a quick edit into a ceremony. The history they keep is real but hard to reach. Buried in a UI built for a full-time librarian rather than an engineer who just wants to see what changed. So teams that have these tools still keep a shared drive on the side for the work that's "too small" to justify the overhead. And teams that can't afford the deployment have nothing but the shared drive and its folder full of _FINAL_revised files.
The reason software's answer never crossed over is technical at root. Git was built for text: files made of lines, where a change is a line added or removed, and two edits can often be stitched together automatically. Engineering data is almost never text. A STEP file or a SolidWorks part is a dense binary blob. Flip one feature and the bytes scramble in ways no line-based tool can read. Git alone can't handle that, so engineering was left to the PDM vendors, who solved the binary problem but reintroduced all the enterprise weight Git had shed. OpenVault's bet is that you can have both: Git's lightness and the binary-file handling engineering actually needs. See how CAD version control works for the full picture.
What OpenVault actually is
OpenVault is version control built for engineering data. Underneath, it's Git and Git LFS, the same systems software teams already trust, wrapped in a workflow that understands CAD files, BOMs, drawings, and simulation results instead of source code.
In plain terms:
- Every change becomes a commit with an author, a timestamp, and a message.
- You can branch to explore a design variant without touching the main design.
- You can diff two revisions to see exactly what changed.
- You can do all of it offline, then sync when you're connected.
And this is the part that matters most: you can do it without becoming a Git expert first. The commands mirror Git on purpose, so anyone who already knows it feels at home. For everyone else, OpenVault hides the parts of Git that have nothing to do with your job: LFS configuration, remotes, merge strategies. You get the workflow without the homework.
What it does, and what it deliberately doesn't
It's worth being honest about the hard case, because honesty is the difference between a tool you can trust and one that surprises you later.
OpenVault does not try to automatically merge two people's edits to the same STEP file. Automatic merging of 3D geometry is an unsolved problem, and any tool that pretends otherwise will eventually corrupt someone's work without telling them. So OpenVault doesn't pretend. When two branches change the same file, it flags the conflict and shows you both versions to resolve by hand.
That's the right behavior. A version control system earns trust by being predictable.
Everything else it handles quietly:
- Multi-file changes stay together. A real design revision touches the model, the drawing, the BOM, and the simulation deck. OpenVault tracks them as one commit, so the relationship between a model and its downstream outputs is never lost.
- Large binaries just work. A SolidWorks assembly can be hundreds of megabytes. OpenVault routes recognized engineering files through Git LFS automatically,
.step,.iges,.sldprt,.sldasm,.stl, and the rest, with no tracking rules for you to configure. See our SolidWorks integration for specifics on that workflow.
What a day with OpenVault looks like
The features matter less than the rhythm they add up to. Here's the shape of an ordinary day.
You start the morning by syncing, pulling down whatever your teammates committed overnight. Before you touch anything, you can see exactly what moved: which models changed, who changed them, and the message they left explaining why. There's no archaeology, no Slack thread asking "is the bracket revision in yet?" The answer is in the history.
When you start a real change, say, reworking a mounting bracket to clear a new harness routing, you branch. Now you have a private space to iterate. You can make the model wrong three times before you make it right, and none of that churn touches what anyone else is working from. The main design stays stable while you explore.
When the rework is done, you commit it as one unit: the updated part, the regenerated drawing, the revised BOM line, the re-run simulation. Then you merge it back. Anyone who syncs after that gets the whole coherent change at once. Never the model without the drawing, never the new geometry against the old analysis. The pieces that belong together travel together.
And if someone else happened to edit the same bracket while you were working, OpenVault stops and tells you. It doesn't guess. It shows you both versions and lets a human, the one person who actually understands the design intent, decide. That pause is a feature.
Versioning is also a paper trail
There's a second payoff that's easy to overlook until you need it: every commit is a record.
In regulated industries, aerospace, medical devices, automotive, you are expected to be able to answer "what changed, when, by whom, and why" for any part of a design. Teams without good version control reconstruct this after the fact, badly, from email and memory, usually the week before an audit. Even teams with a PDM system often dread it, because pulling a clean history out of the vault is its own project. It's stressful, it's incomplete, and auditors can tell.
With OpenVault the audit trail is a byproduct of doing the work. Every revision already carries its author, its timestamp, and its rationale, because that's just what a commit is. When someone asks how the design reached its current state, the answer is already there. The same discipline that keeps your team from losing work also keeps you ready for the conversation you hope you never have to have but eventually will. For a comparison of how this stacks up against proprietary tools, see OpenVault vs SolidWorks PDM.
It fits the tools you already use
OpenVault sits underneath the files you already produce, in whatever tool you already produce them with. SolidWorks, Fusion, CATIA, NX, KiCad, Altium. OpenVault doesn't care what wrote the file, only that it can track it faithfully. You keep working the way you work; OpenVault quietly remembers everything you do.
That's deliberate. A version control system that demands you reorganize your whole life around it is a system most engineers will route around within a month. The best tooling is the kind you stop noticing. It earns a permanent place by adding capability without adding ceremony.
You can start today
OpenVault is open source under the MIT license and installs from PyPI:
pip install openvault
openvault init
The CLI is free for local and command-line use, with unlimited files and unlimited history. No license server, no seat count, no sales call.
When a team needs more, a web UI with 3D file preview, role-based permissions, and cloud-hosted repositories with managed LFS storage, those capabilities are available on top of the core. The CLI is free and stays free. ToolCrib adds BOM management and approval workflows for teams that want to take the next step.
Why this is worth doing
Think about where this moves you:
- From "which file is final?" to every file accounted for.
- From lost overwrites to a history you can trust.
- From "we'll explain the change later" to an audit trail that's already there.
Engineering teams have carried the cost of bad version control for years. The lost work, the unclear history, the audits that turn into fire drills. Mostly accepted it as a fact of life. It isn't. The same confidence software teams have had for two decades is available to you now, built for the files you actually work with.
You don't need a six-figure PDM deployment to get there. You need version control that understands your data and stays out of your way. That's what OpenVault is for.