Epic opens Lore version control system for game studios

{{IMAGE:2}}

Epic Games released Lore on June 17, 2026, as an open-source version control system for game, film, and media teams that move large binary files through build pipelines.

Epic wrote Lore in Rust and released it under the MIT license. The company points developers to Lore.org for documentation and its Epic Games GitHub organization for source access.

Product

Epic built Lore for teams that treat textures, meshes, cinematics, audio, and project files as core assets. Git handles source code well, and Git LFS adds large-file storage through pointer files. Epic argues that large binary content needs first-class chunk storage, sparse working copies, and local editing commands that do not ask the server for every routine action.

Game teams know the pain point. A programmer can clone a repo and compile code in minutes. A technical artist may need hundreds of gigabytes of assets before opening a level. A build engineer may need one platform branch, one content slice, and one release stream without dragging every cinematic file into a workstation checkout.

Epic’s design uses a central server as the source of record for durability, access control, and conflict resolution. Developers still stage, commit, branch, and diff on a local machine. Artists get sparse, lazy working copies that fetch the files they need instead of pulling a full depot.

The largest difference sits in storage. Epic says Lore uses content-addressed storage with fragment-level deduplication. That design lets a team store repeated chunks across large files, including multi-gigabyte binary assets. A small edit inside a packed asset should cost less storage than another full copy of the file.

Performance data

Epic has not published throughput, latency, clone time, or CPU figures in the supplied announcement. That leaves buyers and build engineers with design claims, not benchmark proof.

Area	Epic’s claim	Data still needed
Large binary files	Fragment-level deduplication targets multi-gigabyte assets	Storage savings across Unreal projects, film scenes, and texture sets
Local work	Staging, commits, branches, and diffs run without network trips	Local command latency against Git LFS and Helix Core
Sparse workspaces	Developers and artists materialize needed files	First-sync time and rehydrate time on real depots
Server load	Central server handles durability and access control	CPU, memory, disk I/O, and object-store cost under build-farm pressure

Power consumption depends on storage behavior. Lore could cut power draw in a studio server room if deduplication reduces disk writes, cache churn, and object-store traffic. It could raise power draw if fragment indexing costs more CPU than the storage it saves. Teams need wattage at the wall, not claims in a launch post.

A useful test rig would pair a 32-core server with NVMe storage, a 10 GbE network, and a mixed depot: source code, 4K textures, Nanite meshes, baked lighting data, audio stems, and cinematics. A build engineer should measure initial sync, branch switch, commit, revert, diff, and clean workspace creation. The same depot should run through Git LFS and Helix Core so the numbers show trade-offs.

Compatibility

Lore targets studios that need open tooling and large-file scale. The MIT license gives tool vendors and internal pipeline teams room to write clients, integrations, and migration utilities without asking Epic for permission.

Rust gives Epic memory-safety benefits and a modern systems base. Studio engineers can embed Lore tooling in build agents, asset processors, and continuous integration jobs if the command-line interface and protocol stay stable.

Compatibility will decide adoption more than the license. Studios need hooks for Unreal Engine projects, digital content creation tools, review systems, build farms, authentication, backups, and disaster recovery. Teams that use GitHub, GitLab, Jenkins, Horde, TeamCity, or custom asset validation will ask where Lore plugs in before they move a depot.

Git interoperability also matters. Many game teams keep source code in Git and assets in another system. Lore may win mixed workloads if Epic gives teams clean migration paths, history import, branch mapping, and tooling that keeps code review intact.

Build recommendations

Small teams should test Lore on one asset-heavy project before they migrate source code. Pick a branch with real binary churn, then measure sync time, storage growth, and artist workstation setup time for two weeks.

Studios with Perforce depots should run a side-by-side trial. Measure depot size, metadata growth, submit latency, branch creation, and restore time from backup. Add build-farm traffic to the test, because developer laptops do not create the same load as 40 workers pulling cooked content at 9 a.m.

Homelab builders can treat Lore as a storage experiment. Use ZFS or btrfs snapshots, export metrics from the server, and record watts under clone, commit, and branch-switch workloads. Fragment-level deduplication sounds useful, but your power meter and disk graphs will tell you if the design pays off.

Epic has given large-asset teams an open contender in a field long split between Git plus LFS and centralized commercial systems. Lore now needs public benchmarks, editor integrations, and migration tools before production teams can judge it against their current depots.