Do you version pin GitLab self-hosted?

After reading through Create a GitLab upgrade plan | GitLab, I realize it might be considered best practice to version pin my gitlab-(ce|ee) package instead of letting it self-upgrade, and instead planning a head and test a minor (or major) release before upgrading.

What are your thoughts, how are you doing this?


I just upgrade my test server first and make sure it’s working. Then I do updates on my production one.

If you do pin it, you’ll have to remove that so that you can update. I personally don’t see a need for it, but then I’m the only one managing my server. I also update regularly anyway, so I pretty much go through every single Gitlab point release that is released. I’m never in a situation where I’ve not upgraded my server for such a long time, that I need to follow the upgrade path.

Thanks for your comment! :slight_smile:

What do you mean by “letting it self-upgrade”?

GitLab says in the admin area if an upgrade is available, but doesn’t do anything. I guess most Linux distributions (I know Debian has “unattended-upgrades” and most derivatives have probably chosen to inherit that) have a tool for automatically upgrading certain packages, and have some concept of pinning that excludes packages from that.

When you don’t use that for GitLab, it’s just not automatically updated - and that’s how our instance used to work, I just logged in and upgraded it whenever there was a new version (mostly, I might have skipped a version or two over 4-5 years).

In our current setup, we still don’t use any of that, but now our configuration management system is configured to install a specific (pinned) version of GitLab (on certain servers), that is mostly done to make sure all the servers (we have setup dedicated servers for gitaly and praefect, and have a load-balanced setup for the web UI), so the current process is to stop the configuration management, update the specification in that, upgrade stuff and start the configuration management (on some servers we can just let the configuration management do the upgrade, on those the process is just to force a run of that).

We don’t use that for GitLab - but

Sorry for being unclear. What I mean by “self-upgrade” is that it’s being performed by unattended upgrades, being it either apt or dnf based systems.