Lore for Unreal Engine

What it is

Lore is a centralized version control system from Epic Games with local operations that work offline. It splits file content into hashed fragments so revisions can share unchanged data.

Lore currently ships as 0.x software. Epic intends committed data to remain readable in future releases, but APIs and protocols can change before 1.0. Its roadmap targets scalable locking in 2026 and an Unreal Editor integration in 2027, shipped as part of the engine rather than a separate plugin. Neither date is guaranteed.

With Unreal Engine

UEFN uses Lore internally, but the public client cannot connect to Epic's hosted UEFN service. The release includes a CLI, client APIs, and an early desktop-client binary. That desktop client is not open source and cannot open UEFN projects. No public Unreal Editor plugin has shipped.

Where it fits

How it works

Repository and remote

A local repository records the working tree, staging state, revisions, and cached content. A remote server is the shared record for pushed commits. The CLI exposes add, status, commit, branch, switch, merge, push, and sync operations.¹⁵

Content-addressed storage

Lore identifies immutable data by content hash and separates immutable objects from mutable names and lock state. Repeated content can share storage, and tools receive a stable identifier for the bytes they consume.¹

Branches and synchronization

You can branch and switch locally, then exchange revisions with the server through push and sync. If two branches change the same binary asset, someone still needs to choose which revision to keep.

Server storage backends

The server separates immutable content from mutable references and lock state. Zero-config mode puts the content and reference stores under a fixed path in the operating system's temporary directory, while the local lock store lives only in one server process. A durable shared deployment needs explicit storage, authentication, certificates, backups, and a restore path.⁴⁶

Clients and platform support

Lore publishes CLI binaries for Windows, macOS on ARM64, and Linux on x86-64 and ARM64, plus a Docker image for the server. The client library works directly from C, C++, and Rust, with bindings for JavaScript, C#, Python, and Go. An early desktop-client binary exists, but its source is not published and it cannot open UEFN projects.¹²⁴⁵

Current locking model

Lore can acquire, query, and release locks, but the current lock is informational. It does not stop a second person from editing the file. The roadmap lists scalable enforced locking separately, with a 2026 target.²³

In production

1. 01

   Run the local workflow first

   Create a disposable repository, add a representative Unreal project slice, and exercise status, commit, branch, switch, merge, sync, and recovery. Do this before designing a studio-wide service around the APIs.

2. 02

   Test binaries and conflicts

   Use real .uasset and .umap files rather than a code-only sample. Acquire and release locks, then deliberately create divergent binary changes on two branches. Record how the team identifies and resolves the losing revision.

3. 03

   Test the server you would operate

   Lore provides local deployment and reference backends. Configure the authentication, object storage, metadata storage, backup, restore, and monitoring path the studio would operate. Without a [server.auth] block, the gRPC services accept unauthenticated requests. Add one with a JWT issuer and audience before exposing the server to the team. Since 0.10.0 the server refuses to start if either value is missing.⁶

4. 04

   Record the decision against the released version

   Record the exact client and server versions used in the trial. Check whether locks prevented conflicting changes, the required editor integration exists, and backups restored a usable project. Base adoption on those results.

Best practices

Keep the trial disposable

Use a representative copy of code, maps, Blueprints, and source art while the production repository remains in its established system. Pin the client and server release so every result belongs to a known build.

Deploy durable storage explicitly

Move beyond zero-config mode before testing recovery. Configure persistent mutable and immutable stores, trusted certificates, JWT verification, service supervision, monitoring, and backups that survive operating-system cleanup and a server restart.⁶

Test the binary conflict path

Create changes to the same .uasset on separate branches, acquire and release locks, and merge the branches later. The trial needs to show how a producer finds the conflicting revisions and chooses the version that survives.

Test the API the studio would use

Use the same language binding and operations needed by the build farm or editor tool. Record protocol, authentication, error recovery, and upgrade behavior instead of treating the command-line quickstart as an integration test.

List the required features before the trial

Write down whether the team needs enforced locking, the Unreal Editor plugin, open-source graphical clients, UEFN compatibility, or a stable protocol. Compare those requirements with released features, not roadmap dates.

Gotchas

Lore is still pre-stable

Committed content is designed to remain readable, but APIs and wire protocols can change before 1.0. An upgrade test and rollback plan are still required for every pinned release.²

The quickstart server is temporary

Zero-config mode stores data in a fixed lore-server folder under the operating system's temporary directory, which the operating system can clear. It generates a new self-signed certificate for each run, and gRPC requests are unauthenticated when [server.auth] is absent. Configure persistent paths, certificates, and authentication before a shared trial.⁴⁶

Current locks do not enforce exclusive editing

Current locks tell collaborators that a file is in use but don't reject conflicting edits. The built-in lock store lives in one server process. Multiple server nodes need a shared lock backend.²³⁶

The public client cannot use hosted UEFN repositories yet

UEFN repositories were built with Oodle compression, and the open-source client uses Zstandard. Epic is moving UEFN data to Zstandard, but the public client can't connect to the hosted UEFN service yet.²³

Reference cloud backends need a custom server build

The AWS and HashiCorp plugins ship as source but are not compiled into the base server binary. A team-wide deployment must own that build, its credentials, backend configuration, and its upgrade path.⁶

Adoption checklist

• Pin an exact Lore release and assign an owner to review protocol changes and security notices.
• Keep the evaluation repository separate from production source control.
• Test restore from backups rather than relying on forward-readability claims.
• Measure sync, status, branch, and push behavior with real project content.
• Document which roadmap items the team would require before production use.

Related guides

• Perforce P4Centralized version control built around workspaces, changelists, and exclusive checkout.
• Git with Git LFSGit version control with separate storage for large files and optional file locking.
• Unity Version ControlVersion control formerly called Plastic SCM, with Smart Locks, a partial-workspace client for artists, and a built-in Unreal provider.
• DiversionHosted version control with an Unreal Editor plugin and file locks.

Sources

Official sources checked September 24, 2026.

1. 1Lore system designepicgames.github.io
2. 2Lore FAQepicgames.github.io
3. 3Lore roadmapepicgames.github.io
4. 4Lore quickstartepicgames.github.io
5. 5Lore CLI referenceepicgames.github.io
6. 6Lore server configurationepicgames.github.io