People migrating from Github to Gitlab should learn about these details first

After Microsoft’s recent acquisition of Github, a mass exodus has kind of begun and many small and large projects are moving their code bases to the much hyped Gitlab in a hurry, and these include both open and closed source projects. However, before migrating to Gitlab, they should take a pause and learn something about Gitlab and consider evaluating other alternatives too.

Gitlab Stack

Gitlab Stack

According to above chart, Gitlab basically runs on Microsoft Azure cloud hosting facility. So, if you are leaving Github in order to escape the clutches of Microsoft, then you are headed to a totally wrong place! Microsoft is exactly the place where your source code will reside in this case, only difference is that instead of controlling it directly (as in the case of Github), Microsoft will be controlling your code only technically.

I know, some of you will be saying that you are self-hosting an open source copy of Gitlab and not actually moving to In that case, please have a look at another item in that stack, namely Rails (RoR or Ruby on Rails framework).

Though Rails is a great framework that developers enjoy to code with, its a performance hog when it comes to actually running on production! There is a reason why Twitter ditched Rails in favor of Node.js instead of fixing the interpreter like Facebook did with PHP. Apart from Rails being a performance hog, consider that a git hosting facility is not a simple CRUD app. Its very difficult to do advanced things like CI/CD right in a framework like Rails and the effect is showing. It may work out initially, but once your code base starts to increase and your integrations start to scale, you’ll hit the RoR scaling limit sooner or later, like many others have. Its not uncommon for Gitlab to eat gigabytes of your RAM or consume 100% CPU. So, if you are trying to host Gitlab in a small Digital Ocean droplet or Amazon AWS Micro instance, you can just forget about it!

Or, you can sit back and evaluate your options, it really depends on what you basically want. If you just want a free git hosting facility and don’t want to self-host, there is already Github. If you don’t like Microsoft, then you have Bitbucket, SourceForge, Debian Salsa and others too apart from Gitlab, so consider those options too before blindly deciding on Gitlab and falling for their marketing trap.

On the other hand, if you are ready to self-host and have a smaller budget (just for an AWS Micro or Digital Ocean droplet, for instance), then you can use one of the several open source and light-weight git hosting software like gogs, gitea, phabricator and many others and self-host.

Finally, if you have a budget for hosting Gitlab on a larger instance (like AWS Large instance or 2GB droplet from Digital Ocean), then the first question I’d ask you is why not just stick to paid hosting plans of Github (or Gitlab/Bitbucket if you don’t like Microsoft). That will be a lot cheaper and lenient on your pockets than self hosting a copy of Gitlab on a larger instance.

Whatever route you end up choosing, it should be a calmly taken logical decision after due consideration to all facts, not in this Github acquisition frenzy. All the best.




  1. David Hollinger says:

    You know that Gitlab CI isn’t rails, right? The display UI runs in the Rails app, but the CI/CD runners are actually written in Go and are extremely lightweight.

    Additionally, last I knew, GitHub was rails and BitBucket was Java, both are still good applications. (Travis CI is Ruby Sinatra). Great apps are made by great developers regardless of technology. I wouldn’t run an app entirely in Node.js to save my life. I don’t think javascript is performant enough when compared to Ruby, python, Java to completely rely on it for a git app.

  2. Tamás Barta says:

    I ran GitLab at multiple companies, and for myself, and I never ran BitBucket, but I can tell about JIRA (from the same company with the same technology). JIRA uses far more resources compared to *any* rails app I’ve ever seen (even compared to Redmine). This performance comparison seems very unfounded. The only information backing your statements is a 1,5 years old Server Fault question with 5 upvotes. Looks like a edge case to me.
    I believe people are familiar with GitLab, BitBucket, and the others (of course now excluding GitHub), and there is a reason why most of them choose GitLab over anything else. GitLab is packed with much more features then the ones you mentioned together.
    Also AFAIK GitHub is also written in Ruby (according to Wikipedia).

  3. Marcin says:

    Please also add RhodeCode into the self-hosted options along the gogs/gitea/phabricator it’s a good option

  4. David says:

    Eh… I have to disagree with most of the theme on this article. So are you saying that all data in any AWS network is giving all data to amazon? Just because something is running on azure doesn’t mean Microsoft is spying, eating up everything. Kind of a silly argument in todays cloud marketplace. I think the same applies for Github. The difference is Microsoft now has more than a say in the direction of Github.

    Regarding Gitlab. I hosted my own version for awhile now, both on local computers at my house and in aws ec2. It certainly isn’t the fastest application ever. But the part I think people forget is how feature rich Gitlab is. I used Gitlab because of the whole pipeline, issues, service desk, ci/cd, inviting friends/users, ldap integration on and on.

    I also am a huge ruby fan… so I am probably very biased :). That being said, there’s a lot of go components (pages, runner) where performance was a problem.

Leave a Reply

Your email address will not be published. Required fields are marked *