Where your GitLab can be reached from decides who gets to knock on its login page. Choose that boundary on purpose - LAN-only, VPN, or public with HTTPS - and never by accident.
The video gives your server a fixed IP address on your own network, which is exactly right for a team working in one office. The pressure arrives later, usually in one sentence: someone wants to push code from home. There are three honest patterns for answering that request, and they are not equal. One keeps the login page invisible to the internet. One keeps it invisible and still works from home. One shows it to the entire world - and is only acceptable dressed in full HTTPS armour.
👆 Same server, three boundaries. The first two keep your login page invisible to strangers. The third must be dressed for the attention it will get.
Keep the server on its fixed internal address, exactly as the video sets it up, and optionally give it a friendly name through your router or local DNS so the team types a name instead of numbers. The security property here is total: nothing is published to the internet, so no scanner on earth can find the login page, because from outside it does not exist. The cost is equally total - no access from home, from a client site, or from a hotel. For many small offices that trade is correct, and it is where every new install should start while the other habits - backups, updates, passwords - are still being formed.
When work from home genuinely starts, the professional answer is a VPN into the office network. Each team device joins the office network virtually and then uses the exact same internal GitLab address as if it were sitting at a desk. The GitLab ports are never opened to the internet, the login page stays invisible to scanners, and access is granted per device and can be revoked per device. This is the pattern most small teams should grow into, and it has a side benefit: the same VPN protects every other internal service you run, not just GitLab.
Sometimes public access is the honest requirement. Then do it completely. Point a real domain name at the server, and get a proper certificate for it - the appliance's console tooling supports Let's Encrypt, the free certificate service, so the address becomes a clean https:// name with a valid lock icon. What is not negotiable: never publish the plain HTTP login page to the open internet. Without encryption, passwords travel readable to anyone positioned to watch the traffic, and 'our office is small, nobody will bother' is not how automated scanning works. Public means dressed: name, certificate, sign-ups off, admin two-factor on, updates current.
Exposure multiplies the value of every other habit in this series. Sign-ups stay off, so accounts exist only for people you created. Two-factor authentication goes on for admins first and ideally for everyone. Updates stay current, because an old GitLab on the internet is a target with published instructions. And every few months, open the user list and ask who each account belongs to - departed staff with live accounts are the quietest hole in any system. Choose the boundary once, on purpose, and then defend the choice with these four habits.
Watch the network configuration in the video, then decide deliberately which of the three patterns your team actually needs.
▶️ Watch Full VideoThat is normal when you open the server by its IP address with its built-in certificate - the connection is still encrypted, but the browser cannot verify the name. The proper fix is a real hostname with a proper certificate. Never train the team to click through warnings blindly.
Yes. Automated scanners sweep the entire internet continuously, and new public services are typically found within days. Obscurity is not a defence - assume any public login page is already known, and dress it accordingly.
It is the minimum, not the plan. Add two-factor authentication for everyone, disable sign-ups, keep GitLab updated - or better, choose the VPN pattern so the login page is not public at all.