Hey all, I’m Marijn, and I’m building Vault42, an EU-hosted Git service.
I would like to cater to the needs of game developers, and offer them an alternative to GitHub.
Git LFS add-ons are available on the paid plans, but I would like to hear from people who work with large binary assets every day, like textures, audio, models, builds, etc.
A few things I’m trying to understand:
- How large is your LFS store, and how quickly does it grow?
- Is storage the problem, or transfer (teammates cloning, CI pulling assets)?
- Do you rely on file locking for binary files?
- If you have thought about leaving GitHub, what stopped you?
- Do you have any specific CI/CD needs I should be aware of?
What would it take for you to move your game projects to another Git host? Replies here or DMs are both welcome.
About 50 people are on the waitlist so far, and I’d like a few game developers on board to help me get LFS right.
Thanks!
(Waitlist, if you want to follow along: vault42.eu)
Transfer, by a lot. We have one monorepo for about 20 small mobile and web games plus tools and no LFS at all. dist folders, web bundles and APKs never go in and just get rebuilt, and marketing videos sit in a folder outside the repo with only links committed What actually hurts is CI pulling the repo onto 3 self-hosted runners on our own Macs, and when the Mac is off the queue just sits there
Splitting storage from transfer in your questions makes sense, since a small team re-cloning big texture and audio folders in CI could cost more in bandwidth than in stored gigabytes.
Are you planning to price LFS transfer separately from storage? And for file locking, would locks show up in the web UI so artists who never touch the command line can see who has a file checked out?
Hey,
Can’t join waitlist unfortunately, AAA is still Perforce heavy. We get to use Git for Backend work at least though 😁
For that use case, have worked across a few places, and ran into a few different edges, though none have anything to do with LFS unfortunately.
- one org was on GitHub, used Jenkins for CI. We built micro services in multiple repositories, so being able to create repos on a pattern was really useful. We used Cookie cutter + Cruft to template and try to roll out the templates across all the repos when changes were needed, which worked sometimes. Being able to do that reliability in repo would be amazing, but static templates would be a good starting point.
- another was on GitLab. They made heavy use of the organisation/project/subproject/repository kind of structuring, which worked really well except for integration with Go (I think there’s a doc on GitLabs side talking about it now but it didn’t exist back then). Used their CI tooling heavily, integrating renovate for dependency updates and driving iac through it as well (with terraform).
- one smaller org was a monorepo with code in C# - there were a lot more binaries checked in here, though they changed less frequently. Also ran into the windows/Linux line ending fun on all the source code - smoothing that edge would be an awesomely useful feature for onboarding
- most recent org use a monorepo for backend, are using CI and lots of self-hosted runners (for 8hr+ soak load tests), and have a lot of calls into CI and the codebase from Horde (newish unreal/epic ci system). They’re just exploring GitOps stuff for CD - looking at ArgoCd and Kargo. They’re very keen on a “promotion” style flow, if there’s something you want to innovate on there 😊
Apologies I couldn’t help much on the LFS side of things - the smaller org above did try to move into Git and did with one part of the studio for a while, but it made it harder for non-engineers to cross teams and studios because everyone else was P4.
