GitLab CE (Community Edition) is a self-hosted Git repository management platform that provides source code management, CI/CD pipelines, issue tracking, and container registry – all in one package. It gives teams full control over their DevOps workflow without depending on third-party SaaS platforms.
This guide covers installing GitLab CE on Rocky Linux 10 and AlmaLinux 10 with automatic Let’s Encrypt SSL certificates. We will configure the GitLab Omnibus package, set up HTTPS, configure firewall rules, retrieve the initial root password, set up email notifications, SSH access, backups, and SELinux.
Prerequisites
- A server running Rocky Linux 10 or AlmaLinux 10 with at least 4GB RAM (8GB recommended for production)
- Root or sudo access
- A fully qualified domain name (FQDN) pointing to your server’s public IP – for example
gitlab.example.com - Ports 80 (HTTP), 443 (HTTPS), and 22 (SSH) open on your firewall
- DNS A record for your domain resolving to the server IP (required for Let’s Encrypt)
Step 1: Install Required Dependencies
Start by updating the system and installing the packages that GitLab depends on. The policycoreutils-python-utils package is needed for SELinux policy management, and postfix handles outgoing email notifications.
sudo dnf update -yInstall the required dependencies:
sudo dnf install -y curl policycoreutils-python-utils openssh-server openssh-clients perl postfixEnable and start the SSH and Postfix services so they persist across reboots:
sudo systemctl enable --now sshd
sudo systemctl enable --now postfixConfirm both services are running:
sudo systemctl status sshd postfixBoth services should show active (running) in the output.
Step 2: Configure Firewall for GitLab
GitLab needs HTTP (port 80) for Let’s Encrypt certificate validation, HTTPS (port 443) for the web interface, and SSH (port 22) for Git operations over SSH. If you are new to firewalld on Rocky Linux 10 / AlmaLinux 10, check our dedicated guide.
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadVerify the firewall rules are active:
sudo firewall-cmd --list-allThe output should list http, https, and ssh under the services section.
Step 3: Add the GitLab CE Repository
GitLab provides an official repository setup script that configures the Omnibus package repository for your system. Run the following command to add the GitLab CE repo:
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bashThe script configures the gitlab_gitlab-ce repository in /etc/yum.repos.d/. You can verify it was added:
dnf repolist | grep gitlabYou should see the gitlab-ce repository listed and enabled:
gitlab_gitlab-ce gitlab_gitlab-ceStep 4: Install GitLab CE on Rocky Linux 10 / AlmaLinux 10
Install GitLab CE using the EXTERNAL_URL environment variable. Replace gitlab.example.com with your actual domain name. Setting the URL with https:// tells GitLab to automatically request a Let’s Encrypt SSL certificate during installation.
sudo EXTERNAL_URL="https://gitlab.example.com" dnf install -y gitlab-ceThe installation takes a few minutes. It downloads the Omnibus package (around 1GB), installs all bundled components (Nginx, PostgreSQL, Redis, Puma, Sidekiq), and runs the initial configuration. When it finishes, you will see a message confirming GitLab was installed successfully.
If the Let’s Encrypt certificate request fails during installation (DNS not propagated yet, port 80 blocked, etc.), you can reconfigure later. We cover that in the next step.
Step 5: Configure GitLab with HTTPS and Let’s Encrypt SSL
GitLab’s main configuration file is /etc/gitlab/gitlab.rb. If the SSL certificate was set up during installation, this step verifies and fine-tunes the configuration. If it was not, this is where you fix it.
Open the configuration file:
sudo vi /etc/gitlab/gitlab.rbSet or confirm these key settings:
# The URL users will access GitLab at - must match your DNS
external_url 'https://gitlab.example.com'
# Let's Encrypt automatic SSL
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['[email protected]']
# Auto-renew certificates (runs twice daily by default)
letsencrypt['auto_renew'] = true
letsencrypt['auto_renew_hour'] = 2
letsencrypt['auto_renew_minute'] = 30
# Redirect HTTP to HTTPS
nginx['redirect_http_to_https'] = trueAfter making changes, reconfigure GitLab to apply them:
sudo gitlab-ctl reconfigureThis command re-runs the Chef recipes that configure all GitLab components. It will request a Let’s Encrypt certificate if one is not already present. The process takes a couple of minutes.
Verify GitLab services are running after reconfiguration:
sudo gitlab-ctl statusAll services should show run status with their uptime. Key services to check are puma (web server), sidekiq (background jobs), postgresql (database), redis (cache), and nginx (reverse proxy).
Step 6: Retrieve the Initial Root Password
GitLab generates a random initial password for the root user during installation. This password is stored in a file that is automatically deleted after 24 hours.
sudo cat /etc/gitlab/initial_root_passwordThe output contains the initial password on the line starting with Password::
Password: a1B2c3D4e5F6g7H8i9J0kLmNoPqRsTuVCopy this password. Open your browser and navigate to https://gitlab.example.com. Log in with username root and the password from the file above.
Change the root password immediately after first login. Go to User Settings (click your avatar at the top-right) then Password, and set a strong password.
Step 7: Configure Email Notifications
GitLab sends email notifications for merge requests, issue updates, pipeline results, and other events. The default Postfix setup works for basic delivery, but for production you should configure SMTP to ensure reliable delivery.
Open the GitLab configuration:
sudo vi /etc/gitlab/gitlab.rbAdd or update the SMTP settings. This example uses a generic SMTP server – replace with your provider’s details:
# SMTP configuration
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.example.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "[email protected]"
gitlab_rails['smtp_password'] = "your-smtp-password"
gitlab_rails['smtp_domain'] = "example.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
# From address for emails
gitlab_rails['gitlab_email_from'] = '[email protected]'
gitlab_rails['gitlab_email_reply_to'] = '[email protected]'Apply the changes:
sudo gitlab-ctl reconfigureTest email delivery from the GitLab Rails console:
sudo gitlab-rails consoleIn the Rails console, send a test email:
Notify.test_email('[email protected]', 'GitLab Test', 'This is a test email from GitLab').deliver_nowType exit to leave the console. Check your inbox for the test email.
Step 8: Configure SSH for Git Operations
GitLab uses SSH for secure Git push and pull operations. The SSH server is already running from Step 1. Users need to add their SSH public keys to their GitLab profile.
If your SSH daemon runs on a non-default port, update the GitLab configuration. For example, if you have changed the SSH port on Rocky Linux 10 to 2222:
sudo vi /etc/gitlab/gitlab.rbSet the SSH port:
gitlab_rails['gitlab_shell_ssh_port'] = 2222Apply the change:
sudo gitlab-ctl reconfigureVerify SSH access to GitLab works by testing with a user who has added their public key:
ssh -T [email protected]A successful connection returns a welcome message with the authenticated username.
Step 9: Configure GitLab Backups
Regular backups are critical for any self-hosted GitLab instance. GitLab includes a built-in backup tool that captures repositories, database, uploads, and CI/CD artifacts. For full details on backup and restore strategies, see the official GitLab backup documentation.
Run a manual backup:
sudo gitlab-backup createThe backup file is saved to /var/opt/gitlab/backups/ with a timestamp in the filename. You will see progress output as each component is backed up.
To schedule automatic daily backups, add a cron job:
sudo crontab -eAdd this line to run a backup every day at 2 AM and keep only 7 days of backups:
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1 BACKUP_KEEP_TIME=604800The CRON=1 flag suppresses output unless there is an error. BACKUP_KEEP_TIME=604800 is 7 days in seconds – older backups are automatically deleted.
Important: The backup does not include the configuration files /etc/gitlab/gitlab.rb and /etc/gitlab/gitlab-secrets.json. Back those up separately:
sudo cp /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/
sudo cp /etc/gitlab/gitlab-secrets.json /var/opt/gitlab/backups/Without gitlab-secrets.json, encrypted data like CI/CD variables and two-factor authentication keys cannot be restored.
Step 10: SELinux Configuration for GitLab
Rocky Linux 10 and AlmaLinux 10 ship with SELinux in enforcing mode by default. GitLab’s Omnibus package is designed to work with SELinux, but some operations may require additional context rules. If you run into permission issues, check our SELinux troubleshooting guide for a detailed walkthrough.
Verify SELinux is enforcing:
getenforceThe output should show Enforcing. If GitLab services fail to start due to SELinux denials, check the audit log:
sudo ausearch -m avc -ts recentIf you see denials related to GitLab, generate and apply a custom policy module:
sudo ausearch -m avc -ts recent | audit2allow -M gitlab_custom
sudo semodule -i gitlab_custom.ppAfter applying the policy, reconfigure GitLab and verify all services start correctly:
sudo gitlab-ctl reconfigure
sudo gitlab-ctl statusDo not disable SELinux to work around GitLab issues. The Omnibus package handles most SELinux contexts automatically, and any remaining denials can be resolved with targeted policy modules as shown above.
Step 11: Verify the GitLab Installation
Run a comprehensive check to confirm all GitLab components are working properly:
sudo gitlab-rake gitlab:check SANITIZE=trueThis command checks repository permissions, Git configuration, database connectivity, Redis connectivity, and Sidekiq status. Every line should show a green checkmark or “yes”. Address any issues flagged in the output.
Check the installed GitLab version:
sudo gitlab-rake gitlab:env:infoThis displays the GitLab version, Ruby version, database adapter, and other environment details.
Verify the SSL certificate is valid by checking from the command line:
echo | openssl s_client -connect gitlab.example.com:443 -servername gitlab.example.com 2>/dev/null | openssl x509 -noout -datesThe output shows the certificate validity dates. Let’s Encrypt certificates are valid for 90 days and auto-renew through the cron job configured by GitLab.
Useful GitLab Management Commands
Here are the most common commands for managing your GitLab instance. If you need Git installed on Rocky Linux 10 for local development alongside your GitLab server, we have a separate guide for that.
| Command | Purpose |
|---|---|
sudo gitlab-ctl start | Start all GitLab services |
sudo gitlab-ctl stop | Stop all GitLab services |
sudo gitlab-ctl restart | Restart all GitLab services |
sudo gitlab-ctl status | Show status of all services |
sudo gitlab-ctl reconfigure | Apply configuration changes |
sudo gitlab-ctl tail | Tail all GitLab log files |
sudo gitlab-backup create | Create a full backup |
sudo gitlab-rake gitlab:check | Run system health check |
Conclusion
GitLab CE is now running on Rocky Linux 10 / AlmaLinux 10 with automatic Let’s Encrypt SSL, email notifications, SSH access, and scheduled backups. The Omnibus package bundles everything – Nginx, PostgreSQL, Redis, and all application components – so there is minimal external dependency management.
For production hardening, consider configuring two-factor authentication for all users, setting up an external object storage backend for uploads and artifacts, monitoring resource usage with Prometheus (built into GitLab), and replicating backups to off-site storage.
