Epic releases Lore VCS for teams with large binary assets

Epic Games has released Lore, an open source version control system aimed at development teams that manage large binary files alongside source code.

Epic began the project as Unreal Revision Control, the system behind collaboration in Unreal Editor for Fortnite. The company has now opened the project under the MIT License, which gives teams broad rights to use, modify, and ship derivatives without copyleft terms.

Epic built Lore as a centralized, content-addressed VCS. Developers can install clients on macOS, Windows, and Linux, and infrastructure teams can run the server side across cloud environments.

The central pitch targets studios that store code, textures, animation files, audio, build artifacts, and 3D models in the same project. Git handles text with strength, but game repositories often stress Git through large files and lock-heavy art workflows. Epic wants Lore users to treat binary content as a first-class project asset from the start.

Epic says Lore handles content as opaque byte streams through its storage and transport paths. Developers can layer text-aware features on top, but the system does not assume that text deserves special treatment. That design choice matters for teams that ship games, AI models, simulations, firmware images, or datasets with source code.

Lore also reflects Epic's preference for sparse access. Teams do not want each workstation to pull a full monorepo or full asset tree before a developer edits one map, one shader, or one gameplay module. Epic designed Lore so clients fetch the fragments they need from the server, which can reduce network traffic and shorten sync times for distributed teams.

The company also wants Lore to avoid half-applied revisions. Readers should see a consistent project state while writers push changes. For teams that share large assets, that guarantee can prevent broken editor sessions and failed builds caused by intermediate states.

Epic compares Lore with Git, Perforce Helix Core, Mercurial and Sapling. Git gives developers strong revision graphs and a massive ecosystem. Perforce has long served game studios with file locking and large asset support. Mercurial and Sapling address scale through distributed designs.

Epic argues that Lore combines traits those systems split across different products: binary-first storage, centralized control, sparse access, multi-tenant isolation, a full API surface and consistent revision application. That combination gives large studios a reason to test Lore, even if they have spent years tuning Git Large File Storage or Perforce depots.

The MIT License also gives tool vendors room to build around Lore. A studio can embed Lore in an internal pipeline, a cloud provider can host a managed service, and an engine vendor can add editor integration without forcing its changes under the same license.

Teams should treat Lore as a serious evaluation project, not a drop-in migration. Build engineers need to test repository import paths, authentication, backup strategy, access controls, editor hooks, CI behavior and disaster recovery. Artists and designers need lock, sync and conflict workflows that match their existing tools.

A practical trial starts with one asset-heavy project. Put code, binary assets and build scripts under Lore, then measure checkout time, sync time, storage use, CI behavior and user errors against the team's current VCS. Teams should also test laptop workflows, office-to-cloud latency and branch operations before they move production work.

Epic has published prebuilt binaries through its GitHub organization, according to its release materials. Teams that depend on game-scale repositories should read the quickstart, run a pilot and compare results against their current Git or Perforce setup before they commit to a migration.