Lore shows how binary-first version control scales

Lore is an open source version control system built for large binary assets and team-scale repositories.

Epic Games says Lore is already the built-in version control system for UEFN, and the public repo has 6.8k stars. The project is aimed at teams that need Git-like workflows without paying a penalty for huge files.

1. Content-addressed storage

Lore stores repository data by content hash, not just by path and timestamp. That makes it easier to compare history, verify integrity, and reuse data across branches without copying the same bytes again.

The architecture is built around Merkle trees and an immutable revision chain, so each revision can be traced back through hashed parents and hashed contents. For teams that care about tamper evidence and auditability, that is a more explicit model than a plain file snapshot.

• Repository state is represented as Merkle trees
• Revision hashes include parent revision hashes and data hashes
• Content reuse works across history and branches

2. Binary-first storage

Lore is optimized for projects that mix code with large binary assets, especially games and entertainment. Instead of treating big files as a special case, it stores them in chunked form so updates and transfers can reuse unchanged pieces.

That matters when a single asset change would otherwise force a full re-upload or full checkout. The repo description points to binary-first storage, deduplication, and sparse hydration as the main reasons it can scale where traditional text-first workflows struggle.

• Chunked storage reduces duplication for large files
• Reusable chunks speed up updates and transfers
• Shared data lowers repeated downloads

3. Sparse, on-demand workspaces

One of Lore’s clearest selling points is that workspaces can stay light. You can fetch file data only when you need it, which means local setup can start small and grow as the task demands.

That model suits artists, engineers, and build systems that do not need every asset at once. The README also says you can start in local mode in minutes, then scale up as fast as needed.

4. Centralized service with fast branching

Lore is centralized, but it still tries to keep the developer experience light. Branches are described as lightweight mutable references, so creating and switching branches should not duplicate underlying data.

The project also emphasizes caching in front of durable storage, which is meant to help throughput for larger teams and repositories. If your current pain is slow branch churn or heavy syncs, that is the part of the design to watch.

• Lightweight branches reduce overhead
• Caching sits in front of durable storage
• Designed for team-scale throughput

5. Open source tooling and SDKs

EpicGames/lore is MIT licensed, and the repo includes a core library, server, and CLI plus SDKs for JavaScript, Python, C#, and Go. That makes it easier to wire Lore into existing build tools and custom workflows.

The project is still pre-1.0, so interfaces, on-disk formats, and APIs may change. Even so, the open model is a major part of the pitch: the team says it wants a fully open ecosystem built on open standards, not a closed internal system.

• MIT license
• SDKs for JavaScript, Python, C#, and Go
• Pre-1.0, with APIs and formats still evolving

How to decide

Pick Lore if your repo is dominated by large assets, you need sparse checkout behavior, or you want a version control system that treats binary data as a first-class case. It is also a strong fit if you want to build tooling around a documented API surface.

If you need a stable, mature replacement today, the pre-1.0 warning matters. If you want to evaluate the future shape of game and content workflows, Lore is worth a close look now.