Epic Games Lore: an open source VCS built for binaries, not just text

What problem Lore is aimed at, and who it is for

Git stores snapshots of text well and binary assets badly. A game repository is the opposite shape: a few million lines of code next to multi-gigabyte textures, audio and meshes that change often and compress poorly with line-based diffing. Lore is Epic Games' attempt at a version control system for that second shape. The README describes it as "designed for unprecedented scalability of both data and teams", optimized for projects that combine code with large binary assets, and it says it caters to developers and artists alike. The audience is therefore not a web team with a monorepo of TypeScript. It is a studio where a texture artist and a gameplay programmer both need to push to the same repository without one of them waiting on a full clone.

The project is MIT licensed, written in Rust, and organized as a Cargo workspace with crates for the server, storage, client, transport, revision model and protocol. It is pre-1.0. The README carries an explicit warning that interfaces, on-disk formats and APIs may change between releases, so anyone evaluating it is evaluating a moving target, not a settled tool.

How Lore stores data: Merkle trees, chunks and on-demand hydration

The README's architecture section is unusually specific, and it is worth reading literally. Lore is a centralized, content-addressed system. Repository state is represented as Merkle trees plus an immutable revision chain. Data is stored and referenced by content hash, which is what makes comparisons and integrity checks cheap: two trees that share subtrees share the hashes of those subtrees, so a diff is a walk over hashes rather than a byte-by-byte comparison.

Files are not stored whole. They are split into reusable chunks with an indexed lookup, which reduces duplication and, per the README, enables efficient updates and transfer for large binary assets. Change one region of a 4 GB asset and only the affected chunks need to move. A revision's hash signature is derived from its revision state, including parent revision hashes and contained data hashes, forming what the README calls an immutable chain with cryptographic integrity.

The part that changes daily working life is hydration. Workspaces can stay lightweight by fetching file data only when needed, so a checkout does not imply downloading everything. Branches are lightweight mutable references, so creating and switching them is low-overhead without duplicating underlying data. On the server side, a service-backed architecture puts caching in front of durable storage to scale throughput. The system design doc linked from the README is where the chunking internals and on-disk formats are described; the README itself stops at the summary level.

Installing Lore and making a first commit

The README does not walk through installation inline. It points at a quickstart guide and offers a demo-mode one-liner that installs Lore and starts a local server. On macOS and Linux the command is a shell script piped into bash with a --demo flag:

curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash -s -- --demo

On Windows the equivalent is a PowerShell one-liner that sets an environment variable before running the install script:

$env:LORE_DEMO=1; irm https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.ps1 | iex

What you should see, according to the README, is an installed Lore plus a local server running in demo mode, which is the fastest way to reach a first commit without provisioning storage. The README's Get started section lists the quickstart guide as the place to "install Lore and make your first commit", so the exact CLI verbs for init, commit and push are documented there rather than in the repository README. I have not run these commands; the flags above are copied from the README as written.

For anything beyond a demo, note what the repository layout implies. The workspace includes lore-server, lore-storage, lore-aws and lore-hashicorp crates, and a vendor directory, which suggests the server can be pointed at different durable storage backends. The README does not document a production deployment procedure, so treat the demo path as the only install flow the project currently spells out.

The UEFN gap is the limitation that matters most

Lore is the built-in version control system for UEFN, Unreal Editor for Fortnite. That sounds like the strongest possible endorsement until you read the note directly beneath it: today's open source tooling cannot yet talk to the UEFN build, because that build uses a proprietary compression format which cannot ship with the open source project. Epic states it is moving UEFN onto an open compression format, the same one this open source project uses, to close the gap.

Until that happens, the two deployments are separate. Installing the open source CLI does not give you access to UEFN repositories, and the README does not claim otherwise. Anyone who reads "built-in version control system for UEFN" and assumes interoperability is reading the sentence backwards.

There is a second, broader cost. The README warns that interfaces, on-disk formats and APIs may change between releases. For a version control system that is a heavier statement than for a library, because the on-disk format is where your history lives. The release cadence visible in the repository is fast, with v0.8.5, v0.8.6 and v0.9.0 landing between mid-July and the end of August 2026, and the workspace version in Cargo.toml reads 0.10.1-nightly. A format change in that cadence is a migration, and the README does not document a rollback path.

Where Lore fits against the alternatives

The obvious comparison is Git. The difference is architectural, not cosmetic. Git is distributed: every clone carries the full object database, and large binary files are handled by bolting on a separate mechanism such as Git LFS, which stores pointers in the repository and the actual bytes elsewhere. Lore makes the centralized service the core of the design. Content-addressed chunk storage, caching in front of durable storage, and on-demand hydration are all server-side features. You get sparse workspaces and cheap branch switching because the server holds the data and the client asks for what it needs.

That trade has a real shape. A centralized design means the server is on the critical path for fetching data, and the README's scaling claims rest on caching in front of durable storage. Git's distributed model means you can work and commit with no network at all. Lore's model means a workspace can be small on disk in a way a Git clone of the same asset set cannot easily be.

Perforce Helix Core is the other reference point for teams with binary-heavy repositories, and it is also centralized. The README does not draw that comparison itself; it points readers to a FAQ page that covers "how Lore compares to other version control systems". Anyone making a migration decision should read that page rather than infer the comparison from the architecture summary.

Licence, dependencies and the cost of tracking a pre-1.0 project

Lore is released under the MIT licence, and the README frames that choice as deliberate: the project argues a truly open ecosystem is built collectively using open standards. MIT is permissive, so it permits commercial use, modification and redistribution with the licence text retained. That is the extent of what can be said here; specific obligations depend on how you combine Lore with your own code, and that is a question for your own counsel rather than something the README settles.

The upgrade cost is the part to budget for. The workspace version is 0.10.1-nightly, the README marks the project pre-1.0, and three releases landed within roughly six weeks in the middle of 2026. The last push to the default branch was on 2026-09-17. That combination means an adopting team should expect to track releases rather than pin one and forget it. There is a pyproject.toml in the repository root for a test harness named urc, with a pytest configuration that deliberately leaves tmp_path_retention_policy at its default and a comment explaining that changing it leaks a loreserver process on every run. That is a testing detail, but it is a useful signal about how much of Lore's behaviour is still being pinned down in the open.

The dependency surface is broad. The Cargo workspace pulls in axum, blake3, bitcode, bytes, clap and a long list beyond what the excerpt shows, and the SDK repositories for JavaScript, Python, C#, Go are separate projects with their own release cycles. A multi-language integration means tracking several version numbers, not one.

Editorial conclusion

Adopt Lore if your repository mixes source with large binary assets and you are willing to run pre-1.0 software whose on-disk formats and APIs the README says may change between releases. Do not adopt it as a drop-in Git replacement for text-only projects, and do not assume it can serve the UEFN build today: the README states the open source tooling cannot yet talk to it. Before committing a team, verify the install path on your platform, whether a self-hosted server on your own storage is supported, and how the workspace behaves when hydration is partial.

Frequently asked questions

Official sources

1. EpicGames/lore on GitHub
2. License: MIT
3. Project website
4. README
5. Releases