Epic Dropped Lore. The Good, the Bad, and the Hidden Costs.

Epic Dropped Lore. The Good, the Bad, and the Hidden Costs.
Epic open-sourced Lore at State of Unreal. It’s a version control system built for game-scale projects: written in Rust, MIT-licensed, and already running in production as the VCS inside UEFN, where it used to be called Unreal Revision Control.
The headlines wrote themselves. Free, open source, Perforce killer. The reality is more useful than that, and more complicated. Here’s a straight read for studios actually deciding whether to care: the good, the bad, and the costs nobody’s putting in the celebration posts.
The good
Start with what’s genuinely strong here.
- It’s built for binaries. Files are content-addressed and chunked, so editing a few KB inside a multi-GB asset only moves the changed chunks. That is exactly what Git and Git LFS are bad at, and it’s the core reason studios pay for Perforce in the first place.
- It’s free, with no per-seat fee. MIT-licensed, use it however you want. For a studio paying Perforce by the user account (including the bot and integration accounts that quietly add up), that’s a real line item gone.
- Sparse, on-demand checkouts. You pull only the parts of the repo you need instead of syncing the whole terabyte tree. Good for large projects and faster onboarding.
- It works offline. Branching, diffing, and history inspection all work without the server. Perforce can’t do that.
- Access control is built in. Each repo is its own partition and acts as an access boundary, so contractors and NDA’d work can be scoped cleanly. Knowing a file’s hash isn’t enough to pull it.
- It’s Epic, and it’s battle-tested. It has been running under Fortnite and UEFN at scale for years, so it arrives with a track record most version control launches never get. That pedigree is worth something.
The bad
What the launch posts skip.
- It’s a pre-1.0 release. Epic says the storage formats are forward-compatible, but the APIs and protocols can still change before 1.0. You’d be adopting a moving target.
- Locking is informational only. This is the big one, and it’s for the exact teams Lore is meant to serve. A lock tells your teammate you’re editing a file. It does not stop them from editing it too. For binary assets you can’t merge, that collision is the whole problem, and Lore doesn’t solve it yet. Enforced locking is on the roadmap, not in the box.
- No Unreal Editor plugin until 2027. Most artists live inside the editor. Today Lore is a CLI and an API, with a VS Code plugin planned. The in-editor workflow your art team needs is over a year out.
- Unproven outside Fortnite. It scales for Epic. Whether it scales for your team size, your asset mix, and your infrastructure is untested in the wild on this open release.
The hidden costs
Here’s what “free and open source” quietly leaves out.
- Someone has to run the server. Lore is centralized and self-hosted, with a single source of truth. You provision, scale, secure, and back up that server yourself. If you left Perforce partly to stop babysitting a server and a P4 admin, read that sentence again. You’d be trading a Perforce license fee for the cost of running infrastructure: ops time, a cloud bill, backups, someone on call when it breaks. That cost is real, and plenty of teams underestimate it.
- The open version and the Fortnite version aren’t the same yet. The open-source Lore and the hosted Lore inside UEFN currently use different compression formats. Epic plans to converge them (moving to Zstandard) in 2026. So “the thing Fortnite runs” and “the thing you can self-host today” are not the same build.
- Open source doesn’t mean community-run. This is Epic’s project, on Epic’s roadmap, built for Epic’s priorities, which are Fortnite and UEFN at massive scale. If your studio’s need isn’t on that list, it isn’t arriving because you asked. As one example, the roadmap has no CI/CD or build-integration items on it at all.
- Migration is a real project. Moving a studio’s full history off Perforce or Diversion takes planning and time, and Lore’s model works differently (immutable history, no force-push, no rewriting). Budget for the migration itself, well beyond the install.
So should you move?
Depends on where you’re standing.
- On Perforce and sick of the cost and the upkeep: worth a pilot on a non-critical project. Not worth migrating production yet. Wait for enforced locking, the editor plugin, and a 1.0, then reassess. Those are the three things to watch.
- On Diversion or another managed VCS: be clear about the trade. Diversion is managed cloud. Lore is self-hosted, do-it-yourself. You’d be swapping a vendor’s operations for your own. For a team that wants that control, it’s a fair deal. For most, it’s a step backward in convenience.
- Small team on Git or Git LFS and not actually hurting: stay. Lore solves a problem you may not have yet.
- Already deep in UEFN: you’re effectively using it already, and the native path is the obvious one.
The honest summary: Lore is the most promising open version control to land in game dev in years, and it is not ready to be your studio’s production VCS this week. Start a pilot. Watch the roadmap. Don’t rip out Perforce on launch-week enthusiasm.
One thing worth flagging for anyone who cares about build times, since version control is where every build starts. The most interesting part of Lore long term is quieter than the check-in workflow. A content-addressed system knows, by hash, exactly what changed between any two revisions. That’s the signal a build system needs to rebuild only what changed instead of trusting file timestamps. None of that is wired up today, and Epic hasn’t said it’s coming. But it’s the reason we’re watching Lore closely, and it could matter more for your pipeline down the road than for your daily commits.
Never miss a ue5-main update.
Get them delivered straight to your inbox.