Epic Games open-sourced Lore Version Control System in June 2026, and if you run version control for a game or entertainment tEpic Games open-sourced Lore Version Control System in June 2026, and if you run version control for a game or entertainment team, someone has probably already asked you whether it replaces Perforce. This Lore vs Perforce comparison gives you a straight answer, with the tradeoffs that decide it.
You are likely here because:
- You have watched Git LFS strain under a multi-gigabyte level file or a large Houdini cache, and you know Git alone was never built for binary assets.
- You pay for Perforce infrastructure that someone on the team has to patch, monitor, and back up.
- You have lost work, or come close, when two people edited the same non-mergeable binary at the same time.
- You want to know whether a free, modern, open-source system finally lets you drop the license fees and the server maintenance.
- You need an answer you can defend to your studio lead, not a vendor’s sales sheet.
Lore is a real advance, and we will be specific about what it does well. It is also six weeks old and pre-1.0, and it makes a clear tradeoff: a superb storage engine, wrapped in a studio-workflow layer you supply yourself. Its file locking signals rather than enforces, and the server ships no identity or access control, so that layer is yours to build. Whether that fits a production pipeline today is what this comparison settles. Here is the honest version, from a team that has hosted Perforce, SVN, and Git for game studios since 2005.
Lore is Epic Games’ open-source, binary-first version control system, released in June 2026 and still pre-1.0. It handles large game assets far better than Git, but it ships as a storage engine: file locking is advisory rather than enforced, and the server has no built-in identity or access control. Perforce provides enforced locking and full access control today, so it remains the production standard for binary-heavy studios.
Thhe short version
- Lore is Epic’s open-source, binary-first version control, free under the MIT license, and a real step up from Git for large game assets.
- It is pre-1.0 (0.8.x), six weeks old, and grew out of UEFN’s Unreal Revision Control.
- Lore ships an excellent storage engine but leaves the studio-workflow layer to you: file locking is advisory rather than enforced, and the server has no built-in identity, users, or permissions.
- Perforce ships what production studios depend on in the box: enforced exclusive locking, plus users, groups, and path-level access control.
- A free license is not free version control. Someone still hosts, secures, and operates the server and builds the identity and permissions layer around it. Managed Perforce hosting removes that cost.
Table of Contents
What is Lore, and why did Epic build it?
Lore is a centralized, content-addressed version control system maintained by Epic Games, written in Rust and released under the MIT license, with binaries for Windows, macOS, and Linux. Epic announced it at State of Unreal 2026 alongside Unreal Engine 5.8 and the Unreal Engine 6 vision. It is built for the mix that defines game and entertainment work: source code next to large binary assets like textures, audio, and 3D models.
Epic is one of Perforce’s largest users. Lore reads, in part, as Epic solving its own problem: a version control system designed from the ground up for arbitrary content types and very large scale, with a fully open specification and no license fees. Its core design combines content-addressed storage, fragment-level deduplication that works as well on a multi-gigabyte binary as on a kilobyte of text, and sparse, on-demand fetching so a workstation materializes only the files it needs.
From Unreal Revision Control (URC) to open source
Lore did not appear from nowhere. It began as Unreal Revision Control, the versioning built into Unreal Editor for Fortnite, where creators have versioned their islands with it for some time. Many teams still search for URC because that was its name inside UEFN. With this release, Epic opened the library, server, and command-line tools as one project. One caveat worth knowing: today’s open-source Lore tooling cannot yet talk to UEFN’s hosted version, because UEFN uses a different compression format. Epic lists closing that gap on its roadmap.
How Lore handles binaries differently from Git
Git was built for source code and treats binary files as an afterthought, which is why studios reach for the Git LFS add-on and still hit its limits. Lore treats every file as an opaque byte stream on its fast path, so a 2 GB level file gets the same first-class handling as a line of code. For a team whose repository is mostly art, that difference is the whole point, and it is the strongest reason Lore has drawn attention as a version control option for large binary files.
Lore vs Perforce: how they handle large binary assets
The table below sets Lore against Perforce, Perforce Inc.’s product, on the axes that matter to a studio pipeline. It reflects both tools as of mid-2026. Perforce here means the commercial system many studios know as Perforce (formerly Helix Core).
| Dimension | Lore | Perforce |
|---|---|---|
| Maturity | Pre-1.0 (0.8.x), released June 2026, grew out of UEFN | Decades in production, the standard at AAA studios |
| License and cost | Free, open source (MIT), no per-seat fee | Proprietary, per-seat licensing |
| Large binary handling | Binary-first, fragment-level deduplication, sparse fetch | Strong, long-proven handling of large binaries |
| File locking | Advisory today. Signals a lock without enforcing it. Scalable enforced locking is on the 2026 roadmap | Mandatory exclusive locking through the +l (exclusive open) file type |
| Identity and login | None in the server. It verifies tokens but never issues them, so you run a separate auth service before anyone can log in | Built in. Users, passwords, and tickets, plus LDAP, Active Directory, and SSO support in the server |
| Access control | Permissions arrive inside the token, one whole repository at a time or a wildcard for all. No users, groups, or path-level rules in the server | Protections table on the server. Path-level rules per user or group, edited with p4 protect |
| Hosting model | Centralized. You host the open-source server yourself | Centralized client-server. Self-hosted or through a hosting provider |
| Unreal and Unity support | Built into UEFN. A standalone Unreal editor plugin is on the roadmap | First-class, widely adopted Unreal and Unity integrations |
| Branching | Free branching | Streams |
| Operational overhead | You run and secure a young, fast-moving server | You run the server, often with a dedicated tools engineer |
Read the table honestly and two things stand out. Lore matches or challenges Perforce on binary storage and cost, which is a genuine achievement for a first open-source release. Perforce keeps a decisive edge on what a shipping studio cannot compromise on: maturity, enforced locking, and a complete access control system that ships in the box.
Does Lore enforce exclusive file locking yet?
Not yet, and for a production studio that single fact carries more weight than any other line in the comparison.
Lore has locking today, but it is advisory. A user can lock a non-mergeable asset to signal that they are working on it, and Lore prevents two people from taking the same lock. It does not stop someone without the lock from editing that file or pushing a change to it. An independent practitioner who benchmarked Lore against Perforce, SVN, Git, and Git LFS in July 2026 confirmed this, and noted it is consistent with Lore’s own FAQ. Epic’s roadmap lists scalable, enforced locking as in progress for 2026, with the stated goal of enforcing single-editor access across millions of files and thousands of users. It is a planned feature, not a shipped one.
Perforce works the other way. Mark a file as exclusive-open, the +l file type, and a second person cannot even open it for edit while the first person holds it. For binary assets that cannot be merged, a level, a texture, a compiled Blueprint, a source audio file, that hard block is the difference between coordinated work and silently overwriting a colleague’s day. The Unreal and Perforce community has said the same thing for years: past three or four people, teams rely on exclusive locking, and it is a large part of why so many studios stay on Perforce despite its cost and its administration.
This is not a knock on Lore. Advisory locking is a reasonable starting point, and it can hold up inside a disciplined team whose tools all respect the lock. But a brand-new system without enforced locking is not a drop-in Perforce replacement for a production pipeline with binary assets, and honest evaluation has to start there.
Does Lore have users, logins, and permissions?
Not in the server, and this is the gap most evaluations miss entirely.
Download the Lore server, start it, and you have a version control server that any person who can reach the port can read from and write to. There is no user database, no password, no login command, and no permissions to configure. The server has no concept of who you are, because identity is not part of it.
Lore’s design puts authentication outside the server on purpose. The server verifies an access token that someone else issued, and it checks that token against an identity provider’s signing keys. What it never does is issue a token. The open-source code ships a client for the authentication protocol, not an implementation of it. So before your first artist logs in, someone has to stand up an identity service that speaks Lore’s authentication protocol, connect it to whatever identity provider your studio already runs, and keep it available, because when it goes down nobody can log in at all.
That is a real engineering project, not a configuration file. Epic lists OAuth integration on its roadmap, which will narrow the gap. Today the gap is yours to close.
Where Lore’s permissions actually live
Once identity exists, per repository access follows the same pattern. Lore’s server reads a user’s permissions out of the access token itself, and stores none of them. There is no protections table, no groups, no roles, and no administration interface anywhere in the server. Whatever service mints the token decides what that user may do, which means the entire access control model is something you design, build, store, audit, and operate.
The server understands a small permission vocabulary, read, write, obliterate, admin, owner, and migrate, and it applies them one repository at a time. It compares the repository named in the token against the repository being touched as an exact match, with a single wildcard that means every repository. There is nothing between those two settings.
That last detail matters more than it sounds. On Perforce, giving your outsourced audio contractor access to one folder and nothing else is one line in the protections table, and path-level rules like that are the everyday shape of studio access control. Lore has no path-level rule to write. To scope access below the repository, you split the content into a separate repository and link it into the parent, so an access decision becomes a repository restructuring decision.
What a production Lore deployment actually requires
Put the pieces together and the free license covers the storage engine. Around it, a studio still needs to build and run:
- An identity service that speaks Lore’s authentication protocol and brokers your existing identity provider, whether that is Okta, Entra, Google Workspace, or Keycloak.
- A permissions store, with the administration interface, audit trail, and group model a studio needs to answer who granted this person write access, and when.
- Repository registration, because creating a repository calls out to that same authentication service, and the call hangs when nothing answers it.
- An on-call rotation for all of it, since an outage in the identity layer locks every artist out of every repository.
We can be specific about that list because we built a proof of concept around it, not just read the source. Getting an unmodified Lore client to log in against a self-hosted server meant writing an authentication broker for Lore’s token exchange and wiring it to a studio’s existing accounts. Giving anyone useful permissions meant building the access and group model on top, because the server has none. That is the honest measure of the gap: on Lore it is a system you design, build, run, and secure yourself, while Perforce ships all of it as server features you configure in an afternoon. That finished layer is a large part of what managed Perforce hands you.
What Lore gets right
The most important thing about Lore is not a feature. It is the signal. Epic, one of the largest Perforce users in the industry, built a binary-first version control system and gave it away. That confirms what studios have felt for twenty-five years: game development outgrew Git-only workflows, and binary assets need purpose-built version control, not a text tool with an add-on bolted on.
On its own terms, Lore delivers real things. Deduplication and sparse fetching let a workstation work against a very large repository without cloning all of it. Work stays fast offline because everyday operations do not need a server round trip. The whole specification is open and MIT-licensed, so there are no license fees and no lock-in to a proprietary wire protocol. For a team caught between Git’s binary limits and Perforce’s cost, that combination is worth watching, and worth prototyping on now.
Where does that leave it today? Lore is a strong fit for evaluation, prototyping, and smaller teams that can host and operate it themselves and whose workflow tolerates advisory locking. It is not yet the tool to bet a shipping AAA production on, and Epic, to its credit, says roughly the same: it does not expect studios to replace their existing systems overnight.
If Lore is free, why pay for Perforce hosting?
Because the license was never the expensive part.
Lore removes the license fee. It does not remove the server, and it does not remove everything the server leaves out. Someone still has to stand up the infrastructure, secure it, patch it, monitor it, back it up, and be on call when it goes down at the worst possible moment. On Lore that same someone also builds the identity and permissions layer described above, which Perforce hands you as server configuration. Even the Unreal community’s own guidance to new teams makes the point plainly: whatever system you choose, you have to host the server somewhere, on an office machine running around the clock or in the cloud. That hosting, and the engineering time to run it, is the real cost of version control, and it does not disappear because the license is free.
This is the tradeoff studios have made with self-hosted Perforce for years, and it is exactly the burden managed hosting removes. The question is not free versus paid. It is whether your team spends its time building your game or running a version control server, and for a small studio, that is the same people’s time. It is the same calculation many teams already weigh when they compare Git vs Perforce for game development.
Should your studio adopt Lore now, or run managed Perforce?
A straight decision, without the hedging.
Consider Lore now if you are evaluating where version control is heading, prototyping a new pipeline, or running a small team that can host the server itself, has the engineering time to build an identity and permissions layer around it, and whose workflow does not depend on enforced locking. It is genuinely promising, and getting familiar with it early is a reasonable bet.
Choose managed Perforce if you are shipping a production title with binary assets, need enforced exclusive locking today, and want your team building instead of running infrastructure. Perforce gives you the enforced locking and the mature ecosystem now, and managed hosting gives you those without the server maintenance, the upgrades, or the 3 a.m. pages.
For most studios in production, that second path is the safe one this year. Revisit Lore as it matures and its enforced locking ships.
How we run managed Perforce for game studios
Your team builds products. We manage Perforce.
Assembla has hosted Perforce, SVN, and Git for game studios since 2005, and we are the only managed cloud platform that runs all three natively in one place. For a studio, that means the managed Perforce cloud hosting your artists rely on, the SVN some of your pipeline still needs, and the Git your programmers live in, all managed by us, on infrastructure we run and secure. In twenty years, no threat actor has ever compromised our cloud.
The Perforce license is included in our managed hosting, so there is no separate Perforce contract to buy or renew. We handle the servers, the upgrades, the daily backups to Amazon S3, and the monitoring. Your security team gets SOC 2 Type II, GDPR with EU data residency, the EU-US Data Privacy Framework, and AES-256 encryption at rest, documented and ready for review.
Studios have run real production on this.
“We’re saving easily £30k/year with Assembla compared to bringing our own licenses and paying for most of an engineer’s time
Ben Hymers, Technical Director and Co-Founder of Two Point Studios
“Basically, we live on Assembla & Slack. That’s all we need.”
John Romero, Romero Games
That is what managed Perforce buys a studio. Time back for the engineers who would otherwise run the server. Less risk from missed backups and unplanned downtime. And an end to the maintenance headaches that come with self-hosting. We run the infrastructure so your team does not have to.
Ready to see it. Schedule a demo, or book a migration assessment and we will map moving your Perforce, SVN, or Git repositories to managed hosting, history intact. For teams that already know they need dedicated infrastructure, we also run dedicated Perforce hosting. You can start a 14-day free trial as well, no credit card required.
Frequently asked questions
Is Lore free?
Yes. Lore is open source under the MIT license, with no per-seat fee. Hosting, security, and operating the server are still your cost and responsibility, which is the real expense of running version control.
Does Lore replace Perforce for game studios?
Not for production pipelines today. Lore’s file locking is advisory, so it does not enforce single-editor access to non-mergeable binary assets the way Perforce does. Until scalable enforced locking ships, Perforce remains the safer choice for shipping studios with binary-heavy repositories.
Does Lore have file locking?
Yes, but it is advisory. Lore signals who holds a lock and prevents double-locking, but it does not stop a user without the lock from editing or pushing. Enforced locking is on Epic’s 2026 roadmap.
Does Lore have user accounts and permissions?
Not in the server. Lore has no user database, no groups, and no protections table. It verifies an access token issued by a separate service, and it reads each user’s permissions out of that token rather than storing them. A studio designs, builds, and operates that identity and permissions layer itself.
Can Lore use our existing SSO or identity provider?
Only through a service you build. Lore’s server verifies tokens against an identity provider’s signing keys, but the open-source code never issues a token, so connecting Okta, Entra, Google Workspace, or Keycloak means writing and running a broker that speaks Lore’s authentication protocol. Epic lists OAuth integration on its roadmap.
Can you give someone access to one folder in Lore?
Not with a rule on the server. Lore applies permissions to a whole repository at a time, or to every repository at once, with nothing in between. Scoping access to a subfolder means splitting that content into its own repository and linking it into the parent. On Perforce, the same result is one line in the protections table.
Who hosts Lore, and can you run it in the cloud?
Lore’s server is open source and you host it yourself, and its server side is designed to move into cloud services. That means you own the setup, security, backups, and upkeep. Teams that want Perforce, SVN, or Git without running the server use a managed host instead.
What is the best version control for Unreal Engine projects?
For a shipping Unreal Engine project with large binary assets, Perforce with enforced exclusive locking is still the standard, and managed Perforce hosting removes the server maintenance. Git with LFS suits smaller or code-heavy projects, and Lore is worth evaluating as it matures.
