Ask anything to GitLab

27 September 2017, 4:00 pmAsk Question

GitLab is an integrated product that unifies issues, code review, CI and CD into a single UI. GitLab Inc. offers self hosted products and SaaS plans for It is an open source project with a large community, over 1700 people worldwide have contributed to GitLab!

Ask GitLab about:

  • GitLab 10
  • Hosting on GitLab
  • Open Source at GitLab
  • SaaS plans
  • more

Hosted by:

Thanks for all the questions! If you have any more questions, you can always ask us on Twitter: @dzaporozhets @jobvo. We hope to see you in issues!

Learn Something New Everyday,
Connect With The Best Developers!

Sign Up Now!

& 500k+ others use Hashnode actively.

Dylan Frazier's photo

Hey, guys, Thanks for the AMA.

GitLab has over 150+ people working remotely. So my question is can you give any tips/advice for working remotely?

Job van der Voort's photo

VP of Product at GitLab

I think there are two tricks to making it work:

  1. Working asynchronously: write everything down and avoid creating bottlenecks. You want everyone to always be able to continue with their work. So if you write everything down (such as we do in our handbook at, people can consult that instead of having to rely of tribal knowledge.

  2. Realizing that working remotely requires work: It's a very different way of working and you have to actively think about how to communicate, how to build teams, etc. So instead of relying on those micro-communications you have when you're together in the office (e.g. 'watercooler talk'), you have to create opportunities to bond and share. Working remotely means not doing the exact same things but separated by more air, it means working differently so everyone can be more productive and have a more flexible life.

I wrote quite a bit about this, see also here:

Dmitriy Zaporozhets's photo

I 100% agree with what Job said in his response. From my side I can add only minor tips:

  1. Push code frequently, write status update in the issue tracker daily etc. It helps your colleagues know what you are working on without any direct communication.
  2. Provide an async way for colleagues to book meetings with you. For example I use "calendly" tool which allows people book events in my calendar on free time.
  3. Measure your results, not time spent. If you are doing very well, reward yourself with some free time.
James Franko's photo

Today most open source projects are being hosted on GitHub. What are GitLab's initiative to encourage more developers to use GitLab for their open source projects?

Job van der Voort's photo

VP of Product at GitLab

We believe that by building a product that allows everyone to easily and quickly build, test, deploy and monitor their applications, people will slowly move their open source work to GitLab.

We also realise that many people want the largest set of eyes on their open source work, so we allow you mirror your repositories between GitLab and GitHub automatically.

Lastly, we offer all our features (CE, EES, EEP) and completely free CI to all open source projects. That means you can use for any stage in building, testing and deploying any open source project.

Dmitriy Zaporozhets's photo

Talking about the product, I think our biggest advantage here is an integrated product that does more compared to GitHub. For example, powerful CI/CD out of the box. You create the project at and you receive not only code hosting and issue tracker but also CI, container registry, auto deploy etc.

Company wise we are doing our best to help popular open source projects migrate from old systems to GitLab. I hope to see more of them join us in nearest future. This should encourage developers use GitLab for their next open source project.

Also if you use GitLab for your private projects it seems convenient to continue using same platform for open source projects too. I expect us get most of popularity among private projects first. As result it should increase amount of public projects later.

Ankit Singhaniya's photo

GitLab started using Vue and how is it working out for you now?

Job van der Voort's photo

VP of Product at GitLab

I'd say it's working out really well. We've been building new things in Vue and slowly replacing existing components with Vue. It has allowed us to iterate faster and reuse more.

One of our FE engineers gave a talk about how we use Vue recently, it also links to a whole bunch of other things we've written about it. Check it out here:

Dmitriy Zaporozhets's photo

Our frontend engineers love it. We started with using it only for new features and then slowly replace existing components. Working well so far! :)

Siddarthan Sarumathi Pandian's photo

I have to say, the way you fought your downtime with full transparency in February this year was amazing.

So, this is my question for you. Just like how buildings have mock fire drills, do you think programmers should simulate failures?

Let's face it, downtime is bad and no one wants it. That being said, one should be prepared to handle it. A team of engineers can take the test environment down and another team will try to bring it back up. So, when production actually goes down (god forbid), the engineers will be acclimatized to handling it in a nice way.

Job van der Voort's photo

VP of Product at GitLab

Interesting question! I think any piece of critical infrastructure should be either resilient against failures or easily brought up again.

In practice, I wonder if anyone does this against their test instance. In my experience, test instances are brought down involuntary frequently enough that people are comfortable bringing it up again 😅

I do think it's important that every environment is well-instrumented and alerts go out if anything is off.

Dmitriy Zaporozhets's photo

That's interesting idea around having 2 teams fighting for test env. I think if your test environment is quite stable you should definitely try that. Otherwise, you probably have it failing on regular basis.

I think we (not only GitLab but any infrastructure team) should definitely practice recovery on regular basis. Somehow we manage to forget about it until someone accidentally does rm -rf in the wrong terminal :)

Daniel C Lapenna's photo

You are one of the most transparent companies that I have seen. In your opinion how important is it for companies today to be transparent to their users?

Job van der Voort's photo

VP of Product at GitLab

I think being open is the most user-friendly thing you can do. Now your users can hold you accountable. It forces you to be honest at all times, treat your users more fairly and when you do - you find that your users are more understanding and helpful as well.

Not many companies are transparent, but if you are in the position to be more open with your own company, I think that can be a unique advantage.

Dmitriy Zaporozhets's photo

I think it's important because it benefits both users and the company.

Why transparency is great:

  1. It's appreciated by users.
  2. Users can actually help you. There were cases when technical users gave us valuable advice to help with our problem.
  3. It also appreciated by employees. No hidden processes, no need to ask around to get answer on basic questions about company processes.
  4. It's appreciated by candidates. People know almost everything about company before first interview
  5. When everything is public its simple to keep in mind what information is not.
Karan Sharma's photo

Hi, Dmitriy, Thanks for the AMA.

People might have asked you this question thousands of times previously, but I want to hear your opinion on it.

Why should a developer (not so famous) choose to go with GitLab instead of GitHub in 2017? GitHub has many users today, so the chances of getting more visibility are definitely higher if they opted to go with GitHub.

Dmitriy Zaporozhets's photo
  1. If you need to store private projects, GitLab seems like a good place to do so (unlimited private projects)
  2. If you want fully integrated development. Code hosting, build docker image, store it, test code, deploy it etc.

We still have the long road ahead to achieve good visibility in sense of public projects compared to GitHub. But it's getting better year over year.

If still in doubt - you can do development on one platform and mirror to another ( has nice mirror feature) to achieve both rich functionality and public visibility.

Job van der Voort's photo

VP of Product at GitLab

I'd say for you to use the tool where you get things done the quickest (GitLab) and just mirror your repository to GitHub (or BB) if you want the most visibility.

GitLab is not just for hosting your code. It has a very powerful issue tracker, and full CI/CD built-in. That means you can test, deploy in the same place as you have your code. And that saves so much time and effort. It's also completely free for open source projects (everything), CI/CD included. You can even use our Docker Registry to host your Docker images.

Have a look at our comparisons ( or even better - give it a try!

Lallo Vigil's photo

Hi GitLab,

What do you look for in new hires? Thanks for doing the AMA!

Job van der Voort's photo

VP of Product at GitLab

Of course that strongly depends on the role someone is applying for, but as a remote company there are a few characteristics that help a lot:

  • ability to work independently: depending on how you organise your time, you might be spending a lot of time working by yourself and having to make decisions without getting direct answers from other people.
  • great communication/writing skills: you'll be writing a lot! Anything that isn't written down gets lost between timezones and the absence of an office. Great writing skills make that you can easily translate your thoughts into words.

We're hiring for a lot of roles and each role has an elaborate job description. Feel free to have a look and apply if you're interested in a particular role:

Siddarthan Sarumathi Pandian's photo

I have one more question for you guys.

I believe competition is a very nice thing and it keeps you on your toes. And as an end user, it gives me a variety of options, so everyone's happy. I actually use GitHub, BitBucket and Gitlab, and I love all of them.

What would you say are your favorite things about your competition (I would assume, that's GitHub or BitBucket)?

Job van der Voort's photo

VP of Product at GitLab

GitHub is responsible for making Git the version control system of choice, if they'd be MercurialHub, maybe we'd all be using that now instead.

We actually hosted the GitLab repository on before we created, so we're happy that GitHub exists!

There is no animosity between GL, GH, BB. We often see each other on conferences and even appear on each other's conferences occasionally. I'm super happy to work in an industry where competitors can treat each other with such respect.

Jan-Stefan Janetzky's photo

would you like to prioritize bugs / feature completeness over implementing more and more Enterprise stuff in future?

Job van der Voort's photo

VP of Product at GitLab

We just want to build a great product. That means fixing bugs and regressions is among our highest priorities, together with building features that our users want and need.

Some of those features will land in our Enterprise Editions, of course. But many others will go towards improving Community Edition.

Ultimately, we want that anyone that uses GitLab can ship cool stuff, quickly and easily. Independent of which version you use. If you are a big organisation or have similar needs, that'll be easier with Enterprise Edition. But we never choose between fixing bugs and introducing more features. If GitLab was full of bugs every release, there wouldn't be a point for building new features!

Dmitriy Zaporozhets's photo

I think we should do both in order to be a successful company. The more successful Enterprise version is the more resources we can allocate toward product in general. Which leads to better general quality, less bugs and more features for both Community Edition and Enterprise Editions.

Arpit Mohan's photo

Thanks for building a great product! I love your ideology around CI/CD (Auto devops, Review Apps). Also, the fact that you're the poster child for distributed teams is incredible.

I wanted to ask what tools do you use on a daily basis to ensure that everyone on the team is on the same page? Do timezones play havoc in daily sync-ups or meetings in general?

Job van der Voort's photo

VP of Product at GitLab

We use GitLab for almost everything, but also use:

  • Calendly to schedule meetings
  • the Google suite of tools
  • Slack
  • Zoom for meetings and webcasts

We have no choice but to deal with timezones daily, so we make it work. Working asynchronously makes that you don't need to have everyone present in every meeting, so we often have meetings that work for maybe 2/3 of the world (morning in place A, end of day in place B) and make sure whomever can't attend knows where to read up.

Dmitriy Zaporozhets's photo

I think the key to timezone problem in meeting, as well as any attendance problem, is to write everything down. Then no matter if you can't attend because of time difference or for other reason, you can always read it later.

tetiana chupryna's photo

Firstly, I must say that I admire your transparency policy in GitLab. It serves as a great source of inspiration for me in my work.

However, now I'm using GitLab on a daily basis, and when I see information about downtimes or some issues, it makes me sad. It's because I know that with high probability my work routine will be affected by those failures.

So here is my question: in your opinion, what is better for a product or a company – be transparent and let people see that nobody's perfect or make an impression of being reliable and trustworthy?

Job van der Voort's photo

VP of Product at GitLab is not stable enough yet, but we're working hard on improving that. Most of our customers run GitLab on their own infrastructure, where this isn't a problem, as is several factors larger than any customers' instance.

Trying to give off the impression that your service is reliable while it's clearly not is not inspiring confidence. It's better to be transparent and communicate what you're doing to resolve the issues with reliability.

Deactivated User's photo

Hey guys, thx for the AMA. What is a long-term mission of the gitlab in front of competitors? Any plans to go beyond development platform?

Cheers Dmitriy from the former coworker ;)

Dmitriy Zaporozhets's photo


Our long-term vision is to become the most popular collaboration tool for knowledge workers in any industry. But first, we need to become #1 platform for developers. Which is quite a huge goal considering our scope: from chat and code hosting to CI/CD and monitoring of a deployed applications.

Cheers from Kharkiv :)

Carine Mothé's photo

Thanks for hosting this AMA. GitLab is awesome, why do you think many popular open source repositories are not on GitLab today? What are the initiatives you are taking to deal with the elephant in the room?

Job van der Voort's photo

VP of Product at GitLab

Someone else asked the same question, which both DZ and I answered here:

We're actually seeing a lot of open source projects moving to GitLab. Some times on their own instance, some times on But we're still a magnitude smaller than GH when it comes to open source projects on We believe it's a matter of time. GH has been around for a very long time and gets the most eyes still. And we understand that, so we've made it easy for you to mirror your repository between GH and

We're making sure that is becoming more stable and much faster. By building the best possible place for someone to build and ship software, we believe it's a matter of time before more open source projects will move to GitLab.

Cho, Yongjoon's photo

First of all, thank you guys for this AMA.

I'm interested in designing UI/UX for complex system like GitLab. How do you share ideas and make design decisions?

Job van der Voort's photo

VP of Product at GitLab

Through any channel we have and with a combination of intuition, research and experience.

On of our UX'ers wrote a long article on how we redesigned the navigation, there's a lot more there:

Dmitriy Zaporozhets's photo

We do everything in issues and design is not an exception. When we have idea we create an issue and then someone from UX team comes up with screenshot/mockup of it. Mockups and feedback are posted as comments in the issue. It continues up until approval either from product person or other designer. In the end we have issue with description of what should be done and final screenshot attached.

There is also UX channel in Slack where UX team discuss new techniques and approaches.

Tommy Watson's photo

Why did the Gitlab Team choose Ruby for development?

Dmitriy Zaporozhets's photo

GitLab started as the weekend hobby. Ruby was my favorite language back in 2011. I wanted to make something useful and practice my skills at the same time. Thanks to Ruby and Rails I was able to release the first version within a month.

Job van der Voort's photo

VP of Product at GitLab

To add to DZ: Today we continue to use Ruby, as it allows us to iterate very quickly.

We also use Go for specific pieces in the backend and of course plenty of Javascript on the frontend.

Ygor Lazaro's photo

Hi people, you team made a really nice job!

I want to ask something kinda particular, but do you guys see GitLab's position at market as a David against a Goliath at the opensource?

I asked because opensource software is mainly at GitHub. Codeplex is closed, so is Google Code and maybe SourceForge is going to the same direction. I just see you and Atlassian working a viable alternative, and mainly being used by closed source projects.

Job van der Voort's photo

VP of Product at GitLab

A little bit! When we were only 5-6 people, our competitors already had teams in the hundreds. Today, we're so lucky that GitLab is well funded and over 180+ people strong.

In terms of our product, I think it quickly became clear to us that an integrated product was a massive advantage. We only integrated CI a few years ago and today we were rated as top tool in a comparison with leading CI products in both current offering and strategy by Forrester.

So in terms of size: yes! But I think our product is the strongest 😁

Dmitriy Zaporozhets's photo

We'll catch up. We have a good, feature rich, integrated product. We started as self-hosted product and we have a leading position here now. Next step is making a most popular SAAS for private projects and then we go for public one. Of course, it won't happen in a day. We need to put a lot of efforts to make as stable and performant as we want. But I am quite confident in it.

Tommy Watson's photo

Does GitLab have open salaries? If not, are you considering to do it soon?

Job van der Voort's photo

VP of Product at GitLab

No and we don't plan to make them open. We believe that is private, personal information.

However, we base our salaries on a calculator that is open. You can view the one for developers here, for example:

We do a lot of work to update that calculator regularly and actively listen to any feedback.

Robert Nsinga's photo

I just created a fresh GCP cluster, successfully linked it to my project settings (under Kubernetes integrations) and now I'm a bit confused by a failing "staging" job that returns Unable to connect to the server: x509: certificate signed by unknown authority ERROR: Job failed: exit code 1. Btw, I'm following this tutorial ( and I can't go past editing the.gitlab-ci.yml config file KUBE_DOMAIN value which is the IP of my Kubernetes master. Any reaction is most welcome. And yes I did a kubectl describe -o yaml and copied the ca.crt and token values into the appropriate fields.

Show +3 replies
Robert Nsinga's photo

Cool stuff and whatnots...

Hey @Dmitriy... before I make another attempt, I gotta let you understand that GCP is deprecating the Kubernetes dashboard. So I access my secrets using kubectl CLI kubectl describe secret/<default-secret> -o yaml. How badly copied can it be?

Robert Nsinga's photo

Cool stuff and whatnots...

@Job and @Dmitriy, after looking into issues on gitlab, kubernetes, and GCP online, I found out that after entering http://<cluster-IP>/ui in the browser it automatically resolves to https://<cluster-IP>/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy... And that's the error (at least for me). The fix is to edit the "proxy" at the end and place it here https://<cluster-IP>/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard/. In a few words that's how I got it to work. After I was able to copy the ca.crt and token into my gitlab configuration. I can now breathe a little -staging passed, yay!... but I can't open the staging URL 😒. I guess I gotta figure out how to access the pods in the browser. From I am able to make a few edits from the staging terminal, but I can't temporarily view them in the browser using the generated URL. Any pointers?

Sai Kishore Komanduri's photo

Hi GitLab, thank you for hosting an AMA! Lot of love to you guys for the work you have put in the community edition. ❤️

Right now CE is available to host on Linux distributions. Do you have any plans for macOS and Windows? Are there any technical bottlenecks that are stopping you to ship the CE to be hosted on these OSes?

Dmitriy Zaporozhets's photo

Thank you for kind words.

GitLab can run on macOS (I do development on it for years without any VM). But Windows is the problem. Most of our dependencies are quite Linux/Unix specific and until those are ported to Windows it's unlikely we can run server code on it.

Job van der Voort's photo

VP of Product at GitLab

There is no real reason to host GitLab on macOS or Windows. You can run GitLab Runner on both platforms, so testing, building, deploying etc all works for everyone!

Installing and maintaining GitLab is ridiculously easy: it's never been a reason to not adopt GitLab! For all the way to deploy, see:

GitLab's dev kit does work on macOS (and I believe even Windows).

Amio's photo

First of all thank you guys for this AMA!

Would you consider an "on-demand" plan? Eg. per pipeline minute, per feature per month, etc. For users (like me) who just need 1 or 2 features in silver/gold plan package.

And, what about "codeowners"? Is it on your plan?

Job van der Voort's photo

VP of Product at GitLab

It's not a smart move on our part to charge you per-feature, because that makes it hard to create an integrate experience and give you powers you never knew you needed! We might introduce per-X billing in the future for pipeline minutes or additional storage.

Yes, I do hope to bring code owners to GitLab in the near future! I don't think we'll ship it this year, but I can imagine it somewhere next year. Issue for it here:

Andrei Anisimov's photo

The build runner that can be run on our servers is the main feature why we use gitlab. Most competitors are lacking this. Do you plan to kill it and move to managed builds at some point?

Job van der Voort's photo

VP of Product at GitLab

No. We'll never take that away. We realise it's a big strength of GitLab.

We already offer shared runners to build/test/deploy your code. They are free for open source projects and private projects have a limit in build minutes, which can be expanded through our subscriptions for (

Most of our customers run their own instance on their own infrastructure and they should be able to use GitLab to its fullest as well. So we make sure they can use GitLab Runner no matter what or where.

Dmitriy Zaporozhets's photo

No way. This is one of my favorite features in CI architecture. It stays for long.

P.S. Glad you like it :)

Jitendra's photo

According to you what are main advantages of Gitlab over Bitbucket (Stash) server?

Job van der Voort's photo

VP of Product at GitLab

With GitLab you can actually go from idea all the way to production, quickly and easily. You don't need to set up and use external integrations and have a powerful issue tracker, CI/CD, wikis, and much more.

For instance, to deploy and monitor a simple app, all you have to do is enable AutoDevops in your project and GitLab will take care of the rest. It's very powerful, see the video here:

If you still want to use your own tools, like JIRA, GitLab integrates really well with them. And lastly, GitLab is improving every single month with large jumps. We just renewed our navigation and it's now super easy and quick to jump between your projects and groups.

Alysson Melo's photo

Hi Guys, thanks for the AMA. Who is your perfect customer?

Show +1 replies
Dmitriy Zaporozhets's photo

We love them all. They contribute to product in many ways, from feedback and bug report to actual feature contributions.

Job van der Voort's photo

VP of Product at GitLab

Yeah, that's a cool thing: customers contributing code. That only happens in a company like GitLab and make the product 1000x better.

Tony Alves's photo

I have recently been proofing out a Netlify automatic deploy (JAMStack) project using the API and (oAuth). Do you have any active discussions going on with the JAMStack community on supporting the API going forward? Specifically provider companies like Netlify.

By the way, the proof of concept went well so far. Hosting a couple sites from Netlify with automatic deploys from GitLab!

Job van der Voort's photo

VP of Product at GitLab

I had a quick search and not that I'm aware, but anyone can make an issue on our issue tracker to suggest it - or even contribute it!

Would love to hear more what you'd need. Feel free to create an issue on

Want to read more?

Browse featured discussions

© 2020 · Hashnode