Deploy GitLab on Self-Hosted Infrastructure

The lesson walks a team member through a self-hosted GitLab architecture, then deploys a Linux virtual machine, configures DNS records, and installs the GitLab Omnibus package. It finishes by configuring the TLS certificate and root access credentials, then setting up and verifying SMTP so new users can receive sign-up confirmation emails.

The trainer explains that self-hosting on private infrastructure lets an organization apply its own security rules, such as firewall rules, which reduces the risk of leaking source code or infrastructure-as-code configurations to outside users or attackers. Resiliency is also discussed as a factor when choosing a hosting model.

GitLab does not typically provide TLS certificates or transactional email on its own, so the lesson connects it to a Let's Encrypt certificate, a DNS provider for a child domain such as gitlab.cbttrevor.com, and Amazon Simple Email Service for SMTP. The virtual machine runs on DigitalOcean, and the trainer notes that steps will differ for other cloud providers.

The lesson opens the gitlab-rails console, which takes about a minute to initialize, and runs a Notify test email command from the interactive Ruby terminal. A Delivered Mail message confirms GitLab can reach the SMTP provider and send email.

The lesson runs 54 minutes and is part of an expert-level course of about 9 hours and 18 minutes per learner. Training Managers should expect learners to already understand GitLab fundamentals, and entry-level IT practitioners may need prior GitLab exposure first.

Training Managers can use CBT Nuggets Playlists to assign the right modules from the Advanced GitLab and DevOps Training course to engineers who will run self-hosted GitLab. Team reporting then shows per-learner progress and completion, cohort and group views, and completion exports for audit evidence.