I’ve been using GitLab for my private projects for years now. I just started using it at some point and never had a reason to switch.

How I ended up here

Back when GitHub still charged for private repositories, GitLab offered them for free. That was the initial hook. I had a bunch of small projects and experiments that I didn’t want to publish but also didn’t want to pay for. GitLab was the obvious choice.

GitHub eventually made private repos free too, but by then my workflow was already built around GitLab. All my CI pipelines, Docker images, deployment scripts - everything pointed there.

The Docker registry thing

Every GitLab project comes with a Container Registry. This is probably the feature I use most.

The workflow is simple. Build an image locally or in CI, push it to the registry, pull it wherever you need it.

No separate Docker Hub account. No thinking about pull rate limits (remember when Docker Hub introduced those and broke half the internet’s CI pipelines?). No managing access tokens for yet another service.

For my private projects this is perfect. I don’t need the discoverability of Docker Hub. I just need a place to store images that integrates with my existing authentication.

The 10GB limit per project sounds small on paper but I’ve never come close to hitting it. Old tags get cleaned up, base layers are shared, and most of my images aren’t that big anyway.

CI/CD

GitLab CI was one of the earlier “CI config as code” implementations that I used. You drop a .gitlab-ci.yml in your repo and things start happening. The config is versioned with everything else, which means you can see exactly what your pipeline looked like six months ago.

Nothing fancy. Build the image, push it, optionally deploy. The manual trigger on deploy is nice - I can build automatically but still control when things go to production.

The shared runners GitLab provides handle most of my workloads. They’re not fast, but they’re free and reliable. For the times when I needed something specific - like a runner with more memory or access to my private network - setting up my own runner on a cheap VPS was straightforward. Install the runner, register it with a token, done.

The documentation for CI/CD is extensive. Almost too extensive. There are so many features and options that finding what you need can take a while. But once you figure out your patterns, you mostly copy-paste from your own previous configs.

The annoying parts

Let’s talk about what’s not great.

Speed. The GitLab web interface has always felt sluggish to me. Click on a merge request, wait. Switch to the pipeline view, wait. Open the job log, wait. It’s not terrible, but there’s this constant friction that adds up over a long session.

I’ve noticed improvements recently. Either they optimized things or I’ve just gotten used to it - hard to say. But it’s still not as snappy as GitHub.

Feature overload. GitLab tries to be everything. Issue tracking, project management, wiki, snippets, package registry, container registry, security scanning, infrastructure management, monitoring… The sidebar menu goes on forever.

I use maybe 10% of what’s available. Repositories, merge requests, CI/CD, container registry. That’s pretty much it.

This is a double-edged sword. On one hand, feature bloat. On the other, if I ever need something like a private NPM registry or security scanning, it’s already there. I just haven’t needed it yet.

The value proposition

I run about a dozen private projects ranging from active side projects to abandoned experiments I keep around “just in case.” None of this costs me anything. It’s crazy.

My workflow

All my private projects live on GitLab. Prototypes, experiments, half-finished ideas, things I’m actively working on but not ready to share. It’s my digital workshop where I can make a mess without anyone watching.

GitHub is different. That’s where I put things I want people to see.

This split works well for me. I get the collaboration and visibility benefits of GitHub for public stuff while keeping my private mess organized on GitLab with proper CI/CD and container registries.

Some people do everything on GitHub. Some do everything on GitLab. Having a foot in both camps might seem redundant but honestly, they serve different purposes in my workflow.