AMA with


The leading product for integrated software development: issues, code review, CI and CD

Hosted by

Dmitriy Zaporozhets's photoJob van der Voort's photo

27th September 2017, 4:00 pm

This AMA is over!

Thank the host

Message from the host 馃挰

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!

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?

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:

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.

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?

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.

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.

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.

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.

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 :)

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

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:

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

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?

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.

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.

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.

  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.

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!

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

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!

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.

Hi GitLab,

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

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:

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)?

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.

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 ;)


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 :)

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?

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.

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.

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?

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.

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? 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.

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

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.

Why did the Gitlab Team choose Ruby for development?

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.

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.

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?

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:

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.

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.

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 馃榿

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.

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.

Sounds like a problem with the certificate authority. I don't think this is the best place to try to resolve you issues, as we don't have the ability to easily follow up.

Can you create an issue in our issue tracker?

Hey, probably certificate issue. Maybe badly copied credentials from GCP.

Btw take a look at quick start guide I made for GKE + I tested it several times to confirm it works.

Hey @Job, I'm working with the default ca.crt PEM in secrets. Is it self-signed? If yes, is that why staging is rejected? I don't mind filing an issue, but I also want to take this opportunity to have a real one-on-one on this live AMA.

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?

@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?

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?

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.

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).

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

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.

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!

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

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?

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.

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

P.S. Glad you like it :)

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?

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:

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

There is nothing more important to us than feedback. A customer that uses GitLab and provides us feedback is 馃殌

What I've personally really enjoyed is getting customers with new use cases or a new scale. Today there are teams of 1 and teams of 30,000 using GitLab intensively. That is exciting.

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

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