Epic open-sourced Lore. Here is how it works.

On June 17, 2026, Epic Games released Lore, its version control system, as open source under the MIT licence (The Register, Phoronix). Lore is already the built-in version control for UEFN. The public repository contains the core library, the server and the command-line client, with SDKs for JavaScript, Python, C# and Go (GitHub).

Epic labels Lore pre-1.0. Interfaces, on-disk formats and APIs can still change between releases.

The problem it is built for

A game repository is mostly binary data: meshes, textures, audio, scenes. Those files are large and they do not merge. Git handles them through an add-on, Git LFS, that each person has to install and configure. Perforce handles them with a different workflow. Lore is designed for projects that mix code with large binaries, and for the artists and developers who both work in them.

How it stores data

From the architecture section of the README:

• Content-addressed. Data is stored and referenced by its hash, in a Merkle tree. Identical content is stored once, and comparing two revisions is a comparison of hashes.
• Chunked. Large files are split into reusable chunks. Change part of a large file and only the new chunks need to be stored and sent.
• An immutable revision chain. Each revision's signature is derived from its parents and its contents, so history is tamper-evident.
• Sparse workspaces. A workspace can fetch file data only when it is needed, instead of downloading everything first.
• Lightweight branches. A branch is a movable reference, so creating and switching branches does not copy data.

Lore is centralised. A server, with caching in front of durable storage, holds the repository. That is a different model from git, where every clone is a complete copy.

What the CLI is like

We ship the Lore CLI inside LoreOwl, so we have spent a lot of time with it. A few things worth knowing if you script it yourself:

lore clone <repository-uri> my-game
cd my-game
lore status --scan
lore stage art/rock_04.blend
lore commit "Rock pass for the cavern"
lore push

• Use status --scan. Without --scan, status only reports files already marked as changed, so edits made in an engine or DCC tool will not show up.
• Stage directories with --scan too. lore stage --scan . stages everything that changed. Without the flag, staging a directory can quietly stage nothing.
• sync is the fetch-and-update command. There is no pull.
• Check status after a sync. In the version we ship, a sync that hits conflicts still exits with code 0 and leaves the merge pending, so the exit code alone will not tell you.
• Partial checkout is a view file passed at clone time, not a command you run later.
• Locks are built in: lock acquire, lock release and lock query.
• Deleting a branch archives it. The command is branch archive, and history is kept.
• Lore does not record a committer on its own. It does store arbitrary metadata on each revision, and that metadata survives push and clone.

UEFN and the open-source build

The two cannot talk to each other yet. UEFN's build of Lore uses a proprietary compression format that could not be released. Epic says it is moving UEFN to the same open format the public project uses (GitHub).

How LoreOwl uses it

LoreOwl's version control runs on Lore. The app ships the CLI, signs it in with your LoreOwl account, and hosts your repository, so there is nothing to install or configure. Status, staging, commits, branches, merges and locks are all in one panel. On top of Lore we add what a team needs day to day:

• the signed-in user written onto each commit as revision metadata, so history shows who made each change
• a lock column in the file tree that shows who holds a file
• importers for projects coming from git, Perforce or a zip archive

Sources

• EpicGames/lore, GitHub
• Coverage of the Lore release, The Register
• Coverage of the Lore release, Phoronix
• New Lore version control system from Epic Games, GameFromScratch