In the fast-paced video game industry, being able to efficiently manage, track, and collaborate on complex multimedia projects is essential. You need to have a way of iterating quickly, of checking everything works with every release, and of merging together all the code and the assets the team produces.
That’s why today, many game studios, large or small, use version control tools.
Of course, as we discussed in other articles, finding the right version control solution for your team might not always be easy, especially taking into account the specific needs of developers and artists. But luckily, there are now more and more available, and several projects aim at providing good versioning utilities specifically in the context of video games.
However, there is still a question that you will need to answer when picking the best version control tool for your team, which is: “should I go for a SaaS or a self-hosted solution?”.
Well, in this article, we’re going to briefly go over the advantages and the drawbacks of each system so that you can get a better idea of which one best suits your own situation :)
Just before we dive in, let’s briefly sum up what a SaaS or a self-hosted VCS solution is.
It’s important to note though that this crude distinction is quite basic, and we’re simplifying the comparison by grouping together some variants. SaaS VCS could also extend to private servers managed by a third-party provider; and self-hosting can consider both self-hosted private servers, and self-hosted on-prem(ise) servers.
Basically, here, we’re mostly focusing on the difference between “having someone else handle the VCS in terms of hardware and software” (SaaS) or “taking care of everything on your own, from install to maintenance” (self-hosted) :)
Alright so - now, with this in mind, let’s see what are the main differences between those two systems, and which one may be more adapted to certain team structures.
One of the most obvious advantages of SaaS version control systems is that they’re more easily accessible for real-time collaboration (this service being managed by the SaaS provider itself). So usually, even if your teammates are spread across the globe, they can still work simultaneously on the same project and share their results instantly.
Because every designer, artist and developer can easily access the latest version of the game assets and code at any time, it’s also easier to stay consistent throughout the development process and iterate on the project in an interesting way.
All this leads to improved efficiency, faster decision-making, and a more streamlined workflow.
Moreover, since the data is centralised in one place, some SaaS solutions offer really nice features such as automatic conflict prevention, to help teams avoid infuriating afternoon-long merge conflict resolution sessions - ‘cause the system can check continuously whether a file is currently being edited and ensure everyone’s in sync, without people having to manually lock and unlock files.
(Note that this can also be true of a self-hosted VCS, if the version control doesn’t use a Git-like distributed architecture ;))
Video games are strange beasts that mix a lot of different fields of expertise - be it in terms of people’s skills, or in terms of file types and sizes! Handling complex binary assets, and large multimedia files like images, sounds, 3D models or even movies is always difficult.
Nowadays, some VCS solutions are very much focused on managing these large files and allowing game creators to keep all their assets in the same place, whether they are small light scripts or big heavy 4k textures.
And, truth is - a SaaS system is often a nice answer here :)
Indeed, a SaaS tool is inherently scalable: it’s based on technologies that can be boosted by upgrading the hardware and the infrastructure seamlessly. And, of course, because this is handled by the SaaS VCS provider, the game team is free to continue working on their project without all these maintenance headaches.
This “auto-scaling” is also often supported by a lot of other nice-to-haves or auxiliary tools that help facilitate the overall versioning workflow. Usually, SaaS version control doesn’t exist in isolation; rather, it’s part of a broader ecosystem of cloud services. This complete “all-in-one” pack can be a real game-changer for video game creators, because it can simplify the day-to-day project management by keeping everything centralised in one place.
For example, having task management tools, continuous integration, deployment pipelines and review features can be an amazing time-saver and further power team collaboration.
The goal, as always, is to reduce menial manual tasks and automate them to improve the development process itself - and by taking advantage of cloud-based services, game developers can delegate a lot of the boring maintenance issues and, instead, focus on efficiently realising their own dream and making games for all of us.
The third big advantage of a SaaS version control system is often said to be data protection and security. And even if it’s true that there are a lot of super neat and reassuring utilities when using this kind of solution, perhaps there’s also some side-stuff worth remembering when diving into a SaaS VCS.
So, on the plus side, using SaaS version control is obviously excellent as far as data redundancy goes. Since you literally have a remote backup of all your data online, and this data is often also backed up again by the VCS service provider, as part of the reliability they are committed to provide. So, you really run less risk of seeing all your week’s work disappear because of a wrong move! (Typically, cloud providers invest a lot on robust redundancy mechanisms, and they distribute the data across multiple data centres or regions to make sure your project data remains safe and accessible at any time, with as little risk of outage or downtime as possible.)
A SaaS VCS is also considered really secure because, unless they want to go out of business, cloud providers basically need to put a lot of money in installing heavy security measures and guarding everyone’s assets. Of course, any system can be hacked… but at least, they put a lot of effort and capital into making sure it happens as rarely as possible here.
That being said… some people have also pointed out that, while your cloud data is indeed secured from the outside, you also are forced to entrust the cloud provider itself with it! Meaning that, in a world of secrets and dark trades like the one of video games, you might be giving your private data to another company that then just promises it will be cool and not backstab you in any way.
No, let’s be honest - I’m painting a rather dark picture of it and, in fact, most SaaS providers aren’t just terrible sharks lurking and waiting to feed off your data. They’re sincerely concerned about obeying the various regulations and laws regarding data privacy, they comply with all legislations about data storage and sensitive data management, and they respect intellectual property.
I just thought it was worth mentioning this issue so that you also see some of the risks of storing and distributing your data online via a cloud provider, if not every actor in the chain is doing their best to up the quality of the service ;)
Actually, another smaller but notable drawback of SaaS VCS is that, because everything’s online, you need to have the Internet to connect to them and get access to your data. Oftentimes, a SaaS version control tool will have very limited functionalities when used locally on your machine offline - if it has any.
Game studios that want to go for a SaaS VCS therefore need to consider this failure point, especially in regions with unreliable or slow internet infrastructure.
And, also, there’s always the possibility that it’s the service itself that is out. In other words, even though you are connected, the cloud VCS is offline and down for some reason. Although the cloud providers have many failsafes to avoid this scenario, it can still happen and, in that case, you need to have some contingencies in place to address potential downtime and ensure the work can continue offline.
However, you should also keep in mind that a self-hosted system, even if it’s completely on-prem, can fail too - there might be a connectivity problem, some downtime on your data centre, or a maintenance issue that your IT team is working on and prevents you from accessing the data…
Finally, last but not least, there’s the question of price.
SaaS version control systems typically operate on a subscription-based or a pay-as-you-go pricing model. So, while this model provides flexibility by allowing teams to pay only for what they use, it also means you’ll have ongoing expenses. Over time, subscription costs can add up, and perhaps be more expensive than the initial investment of a self-hosted version control solution.
Smaller indie studios or startups with limited budgets may find it challenging to manage these recurring costs - in particular if they can’t accurately predict the thresholds they’ll meet… although, to be fair, most SaaS VCS offer a free base package, and there are some thresholds before you’re required to pay anything :)
For larger game development teams, the problem is a bit different. On the one hand, those companies usually have more money, so they can handle the price of a SaaS version control tool. But on the other hand, the subscription costs of SaaS version control can become substantial. As the team size grows, there will be more and more people in need of access to the service, and you’ll have to pay more and more subscriptions.
This cost scaling can make SaaS solutions less cost-effective for large studios compared to self-hosted alternatives, which may have just a one-time cost upon install. However, it is not always a clear-cut decision since, as we’ll discuss in a second, many self-hosted version control systems have per-seat cost or annual subscriptions, too, and they always require resources on your part…
So ok: SaaS VCS offer a lot of good perks that are really well-aligned with the unique specificities of modern video game creation. They don’t require any set-up or maintenance, give teams instant access from anywhere in the world, they allow for easy sharing and collaboration (sometimes with auto-merge conflicts prevention), they provide seamless scalability, and they usually have a lot of security measures in place to ensure your data stays safe and backed-up.
However, they also introduce some concerns about data privacy, and they may go offline and stop your production if you don’t have a backup plan - plus the ongoing subscription fees (or the pay-as-you-go models) can slowly start to cost a lot in your overall budget.
That’s why some people prefer to turn to self-hosted solutions…
Obviously, as a counterpoint to SaaS solutions, one of the best things with a self-hosted VCS is that you’re totally in control of your data and their management. You don’t store your secrets on a third-party server - you keep everything at home, within your own secured infrastructure (of course - assuming you make sure it’s secured - see next section).
This level of control is really important when you’re dealing with highly confidential intellectual property or proprietary tools, assets or even game mechanics. By keeping the data on a private server, or even on-prem, you ensure that your game’s source code and assets remain completely private.
This complete control of the data also means that you are free to choose how you store it. You can tailor the system to your own needs, even if it means experimenting with some custom workflows. And you can perfectly link the version control system to the rest of your internal tools to craft an end-to-end superbly adapted game development pipeline.
But of course… on the down side, there’s the problem of maintaining and securing all of this by yourself. ‘Cause this “phenomenal data privacy perk” only stands as long as you can guarantee that your system is well-setup and protected.
Maintaining a self-hosted version control system, whether it is on a remote server or directly at your studio, means you have to manage both the hardware and the software infrastructure. This includes buying, setting up and preserving servers, storage devices, and the version control tool itself. In particular, regular updates, fixes and upgrades are often necessary to ensure the system is reliable and secure.
So, contrary to a SaaS version solution where all this is handled by your SaaS provider and your team is 100% focused on creating games, when using self-hosted version control, you’ll almost certainly need to have some IT people dedicated to taking care of it!
By the way, this IT team will also be in charge of handling data backups. It will need to put in place data redundancy mechanisms and it will be responsible for disaster recovery if there is ever any problem - all of which takes time and skills. And any lapses in this area can lead to data loss and big project setbacks, so better be careful…
As we said before, video games often rely on massive assets such as high-resolution textures, 3D models, and complex animations. These big files are heavy on the storage… and also long to transfer!
In that case, on-premise version control is actually a great way to have high-performance access to these large files from within a local office. Teams can retrieve and update assets swiftly, minimising the waiting time and optimising productivity. And even a self-hosted private server, if it is well-located and linked to your studio, can be a real step-up from using some SaaS solution.
(‘Cause yeah, comparatively, using SaaS VCS can be slower and have bottlenecks at various points of the file exchanges, which can be risky if your production is on a tight schedule. Plus, if everyone is downloading the same huge asset at the same time, it will probably bog down the entire studio…!)
On the other hand, being constrained to a local network also means that collaboration is more limited - at least, geographically speaking. If the company is really harsh on security measures, you might not be able to work somewhere else that on the company’s premises (though this is evolving as we enter a new era of post-Covid remote work-friendly setups). Of course, VPN is a common tool for dodging these issues and allowing people to access the private network from anywhere, but it does require some cumbersome setup steps whenever you want to collaborate with the rest of the team.
Depending on how the infrastructure is built, and how the version control tool is made available to the team, cross-team collaboration can also be hindered and therefore slow down the overall process. In a really large studio with multiple teams working on different aspects of a project, coordination can become complex - teams can struggle to share assets seamlessly and maintain consistent project versions, which then leads to potential conflicts and delays. The only solution is then meticulous planning and communication… but this also takes time and skills ;)
Now, though maintaining your infrastructure can be hard, there’s a nice silver-lining in having it all in-house: you can predict and reduce the cost dedicated to this part of your activity.
Indeed, while installing the whole system can be a bit expensive at first, this initial investment can become very cost-effective in the long run, especially for large studios.
Also, you’re not subject to the same unpredictable variations of VCS-related costs as with a SaaS solution. When using on-prem version control, you can get fairly reasonable expectations of the budget needed, and you can allocate the rest of resources with more confidence.
First, as we said before, the costs of SaaS solutions may actually be quite low for a while - if there are even any.
Second, although on-prem VCS doesn’t directly scale the costs when your team expands, it’s not always that clear. Typically, if your IT team grows, then your personnel costs will as well. And actually, some solutions like Perforce or even Github and Gitlab when used on-prem price their service by the number of users - so you’re not necessarily getting the better bargain…
And third, being fully on-prem only works as long as you’re sure you can maintain all of this. So even though it’s technically possible… it can be a big risk to go fully on-prem, and it can actually create a lot of difficulties. You can of course consider those a risk worth taking, but it’s crucial to remember that the initial investment and the subsequent savings cost-wise are just one chunk of the equation; and there are a lot more things to consider before going this route.
Typically - your system might suddenly be endangered if some unexpected twist forces you to adapt to rapid growth or re-provision your pipeline… because a self-hosted solution, especially if it’s on-prem, is way harder to scale properly than a SaaS one.
Game development studios live in a strange industry, where a small studio can suddenly boom and grow wild, especially after releasing a very successful title. (That’s a very-well known phenomenon in the indie community, where two people in their garage can make a completely revolutionary artwork that becomes a milestone for an entire genre! Yes, The Binding of Isaac, I’m thinking of you…)
However, self-hosted version control systems may struggle to adapt seamlessly to these changes. Scaling up the infrastructure to accommodate more people and more data can be tricky - it can be time-consuming and costly. So studios must be really careful when they plan for growth and find where best to direct resources to support this change and avoid bottlenecks.
Even outside of those unique events, more common scaling challenges can be over- or underprovisioning your hardware and infrastructure. Because overestimating the system may result in unnecessary expenses… but underestimating can just lead to roadblocks. It’s essential to find the right balance and analyse your entire studio’s past, present and future state to scale everything as well as possible.
Self-hosted version control systems can offer a high degree of control and customisation. They are interesting in terms of data security and fast local access, or even in terms of budgeting because they make for lower and more predictable costs. But the trade-off to all that is that your studio is in charge of its entire infrastructure and hardware - so you’ll need to deal with data backup, maintenance, and even scaling difficulties.
At this point, you see that there is no perfect answer to this question. It all depends on the situation, such as the size of your team and projects, the security requirements you have, the budget you can afford to spend or your scaling ambitions.
Still, it’s worth noting that, in all generality:
To sum up, picking between a SaaS version control system and a self-hosted solution is an important decision that will have an impact on the entire workflow of the game studio.
Ultimately, there is no one-size-fits-all solution, and each type of VCS has its own advantages and drawbacks. The key is to find the one that suits your team and your project, and to not have your version control tools slow down your creators, but rather empower them to do what they like.
That being said, nowadays, there are a lot of interesting tools for you to explore - and not just the old-timers like Git, PlasticSCM or Perforce.
For example, if you’re a game dev looking for a free VCS SaaS option, then you might want to explore diversion.dev, which is a really cool project with a lot of interesting features that, though it is in-development, is already very promising!