Epic ships Lore, an MIT open-source VCS built to treat binaries as first-class citizens

Epic Games is shipping Lore, its own open-source version control system, and it is explicitly designed for the part of software development most traditional VCS tools handle badly: big binaries. Epic started Lore as Unreal Revision Control, then used it internally and as the version control system built into Unreal Editor for Fortnite. Now it is ready for the wider developer world, and it is not doing the usual “we made yet another Git wrapper” move.

At the core, Lore is a centralized, content-addressed VCS built to treat text and binaries the same way. Epic says “All content is treated as opaque byte streams on the hot path,” with text-aware features layered on top. That means code and assets do not get different philosophical treatment at the storage and transport level. Epic is also betting on a licensing and distribution strategy that makes adoption easier: Lore is released under the MIT License, which is more permissive than GNU-style copyleft licenses. In practical terms, MIT tends to allow proprietary derivatives, so a fork of Lore could be proprietary without triggering the kind of reciprocal licensing requirements associated with GNU.

If you are running teams that live inside Unreal Engine projects, this is not a theoretical problem. Fortnite and similar game pipelines generate enormous binary assets, and those assets often collide with the way older systems optimize around text. Epic frames Lore as a “union” of features from multiple existing approaches. It names Git, Perforce, and Mercurial (and its descendant Sapling) as relevant alternatives, then argues that none of them do everything you want at once. Git is credited with strong revision graphing, but Epic says it treats binaries as “second class citizens,” and it lacks multi-tenant isolation that prevents users on the same infrastructure from accessing each others work.

Perforce, meanwhile, gets criticized on latency. Epic says standard operations require multiple server round trips, which makes it too slow for its needs. Mercurial and Sapling are praised by implication for solving “the scale of source repositories” through distributed architecture, but Epic says they still treat text as king and everything else as second-class data. So Lore tries to stop the usual tradeoffs: make binaries first-class, keep the developer workflow fast, and avoid the architecture compromises that show up when your repo is 80 percent assets and 20 percent code.

Zoom in on what Epic claims makes Lore different from the usual category of tools. It is sparse-by-construction, meaning clients only download the necessary fragments from the server to ensure fewer round trips. Epic also says it eliminates partially-applied revisions, so in-between states are invisible to readers. That is a subtle but important idea for teams, because “half applied” changes are where collaboration gets messy: builds fail, diffs become misleading, and everyone loses time reconciling what state the repository was actually in.

Another design goal is a full-surface API, which Epic positions as language-agnostic enough to let Lore work across a variety of programming languages. The system is also built with deployment reality in mind. Lore is installable on macOS, Windows, and Linux, and its server side is designed to be transportable into different cloud services. In other words, Epic is not only selling a tool; it is trying to make it deployable in the environments where teams already operate.

Where this gets strategically interesting is in second-order effects for companies that already have expensive build-and-release pipelines. Version control is infrastructure. Switching it is rarely just a developer preference decision. It touches compliance processes, access control models, CI/CD integration, developer onboarding, and auditability. Epic’s multi-tenant isolation point matters because it suggests Lore was engineered for shared infrastructure settings where many teams coexist. And MIT licensing lowers friction for enterprises and vendors evaluating internal adoption, since permissive licensing reduces legal uncertainty around modifying and integrating with proprietary systems.

For decision-makers, the question becomes less “is Lore cool?” and more “can Lore reduce operational drag and speed up workflows for binary-heavy projects?” Epic is not shy about who it is targeting. It explicitly says Lore is purpose-built for projects that use large binary files such as games, but it also points to other use cases with heavy binary loads, including AI model builders and systems developers working with large amounts of machine-readable data alongside code. That is a direct signal that the company sees version control as a bottleneck in modern data-and-code pipelines, not just a repository management chore.

Epic has published a thorough quickstart guide, and pre-built binaries are available on GitHub. The practical upshot: Lore is not only a new idea, it is something developers can actually try. If Epic is right about the “union” of design features and the binary-first approach, Lore could pressure incumbent systems by raising the expectation that assets and code deserve equal footing. For boards, founders, and engineering leaders building or buying developer infrastructure, Lore is a reminder that the next competitive edge may not be in the IDE. It might be in the version control layer where speed, access, and artifact integrity quietly decide whether teams ship or stall.