Why I Self-Host GitLab and Still Mirror to GitHub
All my automation lives in git, and for a while that meant GitHub and nothing else. It worked fine. But the enterprise world I work toward runs a lot of self-hosted GitLab, and the best way to learn a platform is to be the one responsible for it. So GitLab CE went into the lab as a Docker container, and it’s becoming the primary home for my repos.
Running your own git server changes your relationship with it. On GitHub, backups, upgrades, and runners are somebody else’s problem. On your own GitLab, you are the somebody. You learn what the upgrade path actually looks like, where the data lives, what breaks when a container restarts, and how CI runners get registered and fed. None of that is visible from the consumer side of a hosted service.
I’m not abandoning GitHub. The plan is GitLab as primary with GitHub as a mirror, which gets me the best of both: full control and enterprise practice at home, plus a public presence that recruiters and other engineers can actually find. Mirroring also means the lab burning down doesn’t take my code with it. One copy is no copies.
The rest of the pipeline plugs in behind it. Semaphore pulls playbooks from git, config backups get committed to a private repo, and the AI coding agents I’ve written about work against these same repos. The git server stopped being a place I push code and became the hub everything else hangs off. That’s worth self-hosting once, just to understand.