Self-hosting means the update bell rings for you. GitLab ships a new release every month and punishes version-skippers - so a small monthly ritual keeps the server safe instead of scary.
Self-hosted servers rarely die during an update. They die during the year of postponement before it, while the version quietly falls behind and the eventual jump becomes a project. GitLab is designed around steady movement: a new release every month, security fixes in between, and an upgrade path with required stops along the way. The teams that suffer are the ones who treat updating as an event. The teams that do not suffer treat it as a calendar habit - same week each month, same checklist, backup in hand.
👆 Versions above are an example. GitLab publishes an official upgrade path for your exact current version - follow that, never a guess.
GitLab publishes a new release every month, with additional security releases in between whenever serious issues are fixed. Each release notes page is, in effect, also a list of known problems in the version before it. An internet-reachable GitLab running year-old code is not a private risk - it is a public catalogue. Even on a LAN-only server, the monthly rhythm matters, because the longer you wait the longer the path home becomes. Put a fixed slot in the calendar now, while the install is young and the update is still a ten-minute errand.
Here is the rule that breaks careless upgrades: you cannot always jump straight to the newest version. GitLab defines required intermediate versions - stops - where database changes and long background migrations must run and complete before the next step is safe. Skipping a stop can leave migrations half-applied and an instance that boots into errors. The supported method is boring and reliable: check the official upgrade path for your current version, note the stops, then step through them in order, letting each version finish its background work before moving on. Boring is what you want from infrastructure.
Before any upgrade, take a full backup and write the exact GitLab version next to it. This is not ritual caution; it follows from the restore rule you met in the backup guide - a GitLab backup restores only onto the same version it was taken from. So if an upgrade goes wrong, your pre-upgrade backup plus the old appliance is the one clean road back, and it only exists if you made it before you started. After the upgrade, do not declare victory at the login screen: let background migrations show as finished, open a real project, and push a test commit. Then delete the pre-upgrade snapshot you took - its job is done.
Your GitLab actually has two layers to maintain. The GitLab application updates on GitLab's monthly path, as above. Underneath it, the Debian system provided by the TurnKey appliance receives its own security updates, which the appliance offers through its normal update prompts - accept them, and restart the virtual machine when it asks, because some fixes only take effect at boot. Teams often maintain one layer and forget the other, then discover the neglect during an audit or an incident. Two layers, two small habits, one monthly window that covers both.
Watch the install in the video - then put the first update date in your calendar before the install is even a week old.
▶️ Watch Full VideoNo. Mandatory stops and the backup-first rule make GitLab upgrades a supervised job. Automate the reminder by all means - but a human should take the backup, walk the path and verify the result.
Plan a one-hour window for a small instance, covering the backup, the upgrade itself and your checks. The upgrade alone is usually shorter - the window exists for the month it is not.
Do not leap to the latest version. Take a full backup, read the official upgrade path, and step through each mandatory stop in order - or rebuild fresh on the current appliance and restore the supported way. Rushing this is precisely how instances break.