GitLab CE

In the Azure Marketplace, search for "GitLab Community Edition on Ubuntu 24.04 LTS". Select Get It Now, then Create.

Pick your resource group, region, VM size (Standard_D4s_v3 minimum) and SSH key. In the network security group (NSG), allow inbound 22 (SSH), 80 (GitLab HTTP) and 2222 (GitLab Git SSH).

Connect as azureuser:

ssh azureuser@<vm-ip>

The first boot takes 5-8 minutes. GitLab runs gitlab-ctl reconfigure to re-render nginx and restart services after the per-VM external_url is set. Wait for /var/lib/sac/data/gitlab-firstboot.done to appear before you browse to the VM. This loop waits for you:

while [ ! -f /var/lib/sac/data/gitlab-firstboot.done ]; do echo "waiting..."; sleep 15; done; echo "READY"

Check the status of every bundled service:

sudo gitlab-ctl status

Every line should start with run:, which means the service is up. If a service shows down:, wait another 60 seconds. Puma and Workhorse can take a moment after the reconfigure.

Print the credentials file:

sudo cat /stage/scripts/gitlab-credentials.log

Note GITLAB_ROOT_PASSWORD and GITLAB_LOGIN_URL. Treat both as secrets. The file is mode 0600 root:root.

Azure VMs with Standard public IPs do not return the public IP through the Azure Instance Metadata Service (IMDS). The build script therefore sets external_url to the VM's private IP.

Before you expose GitLab to real users, set external_url to your actual hostname or public IP and run the reconfigure again:

sudo sed -i "s|^external_url .*|external_url 'http://your-gitlab.example.com'|" /etc/gitlab/gitlab.rb
sudo gitlab-ctl reconfigure

If HTTPS is available (Let's Encrypt), use https://. GitLab then renews the certificate automatically once you set letsencrypt['enable'] = true in the same file.

Browse to http://<vm-ip>/users/sign_in and sign in as root with the password from Step 4.

After you sign in, you land on the welcome view. Create your first project to get a Git remote URL.

Open /admin for the administration overview: users, groups, runners, jobs, settings and monitoring.

GitLab Git SSH listens on port 2222, while the system sshd stays on port 22. Add the port to your remote URL or to ~/.ssh/config:

git remote set-url origin ssh://git@<vm-ip>:2222/root/sample-project.git
git push origin main

• GitLab install root: /opt/gitlab/
• GitLab data: /var/opt/gitlab/
• GitLab config: /etc/gitlab/gitlab.rb
• Repositories: /var/opt/gitlab/git-data/repositories/
• Embedded PostgreSQL: /var/opt/gitlab/postgresql/
• Embedded Redis: /var/opt/gitlab/redis/
• GitLab logs: /var/log/gitlab/<service>/current
• Reconfigure logs: /var/log/gitlab/reconfigure/*.log
• First-boot script: /usr/local/sbin/gitlab-firstboot.sh
• Credentials: /stage/scripts/gitlab-credentials.log (mode 0600 root:root)

GitLab's official backup tool dumps the repositories, database, uploads and container registry into a single tarball:

sudo gitlab-backup create ls -la /var/opt/gitlab/backups/

Store the resulting .tar somewhere off the VM, such as Azure Blob or S3. Restore it with gitlab-backup restore BACKUP=<timestamp>.

• HTTPS: edit external_url 'https://...' in /etc/gitlab/gitlab.rb, set letsencrypt['enable'] = true, then run sudo gitlab-ctl reconfigure. GitLab obtains and automatically renews a Let's Encrypt certificate.
• Restrict the NSG: limit ports 22 and 2222 to your management CIDR, and limit 80 and 443 to your CDN or office IPs only.
• Enforce 2FA: go to Admin, then Settings, then Sign-up restrictions. Or enforce it per user under /profile/two_factor_auth.
• Sign in with SSO: GitLab supports OIDC, SAML, LDAP, Azure AD and Microsoft Entra ID. Configure it in /etc/gitlab/gitlab.rb, then reconfigure.
• Patch monthly: run sudo apt-get update && sudo apt-get upgrade && sudo gitlab-ctl restart. GitLab CE releases patch versions monthly and a major version every quarter.
• Back up before upgrades: run sudo gitlab-backup create, then sudo apt-get install gitlab-ce.

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for GitLab CE. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.xlarge or larger. GitLab Omnibus needs at least 4 GB of RAM, and a busy server with 50+ users wants m5.2xlarge. Choose your EC2 key pair under Key pair (login).

Under Network settings, select your VPC and subnet. Create or select a security group that allows inbound port 22 from your management network and inbound ports 80 and 443 from the networks that will access the web interface. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialization rewrites external_url and rotates the root password. It takes approximately three to five minutes after the instance state becomes Running and the status checks pass.

This command launches an instance from the SecureAnyCloud GitLab CE Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22, 80 and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.xlarge \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=gitlab-ce-01}]'

On success, the command prints a JSON document. Note the instance ID. Once the instance is running, retrieve its public address with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from Step 2. The SSH login user depends on the AMI variant you launched. For the GitLab CE on Ubuntu 24.04 variant, the login user is ubuntu.

The firstboot service waits for GitLab to be serving before it rotates the root password. First boot therefore typically completes a couple of minutes after the SSH daemon comes up. Confirm that the sentinel file is present before you read the credentials file:

ssh <login-user>@<public-ip>
sudo ls -la /var/lib/sac/data/gitlab-firstboot.done
sudo cat /root/gitlab-credentials.txt

The credentials file is plain text. It contains the GitLab URL, the sign-in URL, the root username, the rotated root password and the Git SSH port. Copy these values somewhere secure, such as a password manager or an encrypted vault. Do not commit them to source control.

From the same SSH session, confirm that the deployment is healthy:

curl -fsS -o /dev/null -w 'sign-in HTTP %{http_code}\n' http://127.0.0.1/users/sign_in
sudo gitlab-ctl status

A sign-in HTTP 200 response, together with a gitlab-ctl status output that lists every bundled service as run:, confirms that the full GitLab stack is serving requests.

Open http://<public-ip>/ in a web browser. GitLab shows the Community Edition sign-in page.

Enter the username root and the password from /root/gitlab-credentials.txt, then select Sign in. GitLab shows the personal dashboard for the root administrator.

The dashboard surfaces your projects, groups, work items, merge requests and a quick-start panel. It also displays the upstream security advisories that the GitLab maintainers want every administrator to act on, such as the public sign-up restriction reminder.

By default, the GitLab Omnibus package lets anyone who can reach the instance register an account. For a private deployment, select Deactivate on the sign-up restrictions banner on the dashboard. Alternatively, open the admin area at http://<public-ip>/admin/application_settings/general and clear the Sign up enabled checkbox.

While you are in the admin area, open the root user under Admin, then Users, and select Edit. Set a real email address so password recovery and system notifications reach you. You can also rotate the root password from the same page if you prefer not to keep the value generated at first boot.

Open the Projects area in the left-hand navigation and select New project. GitLab shows a chooser of project templates. For a fresh repository, select Create blank project.

Give the project a name and choose a visibility level (private, internal or public). Tick Initialize repository with a README if you want a starter commit, then select Create project. GitLab provisions the bare repository on the dedicated Gitaly volume at /var/opt/gitlab/git-data/repositories/.

The Explore projects area at http://<public-ip>/explore lists every project on the instance that you have access to.

To clone the new project over HTTPS, use the URL from the project's Clone dropdown with your username and password:

git clone http://<public-ip>/root/my-project.git cd my-project echo 'Hello GitLab' > README.md
git add README.md
git commit -m 'first commit'
git push

To use Git over SSH instead, paste your public SSH key into Edit profile, then SSH Keys, in the GitLab UI. The image serves Git SSH on the same port 22 that you use for shell access, with the special git user:

git clone git@<public-ip>:root/my-project.git

Confirm that GitLab SSH is responding by checking for the gitlab-shell banner:

ssh -T git@<public-ip>

GitLab replies with Welcome to GitLab, @root! if the SSH key is associated with your user.

GitLab CI needs at least one registered Runner to execute pipeline jobs. The simplest pattern is a separate EC2 instance that runs gitlab-runner and is registered against this server.

In the GitLab UI, open Admin, then CI/CD, then Runners, and select New instance runner. Choose Linux and select Create runner. GitLab displays a registration token. Copy it.

On a second small EC2 instance, install the Runner and register it with the token. A t3.small is sufficient for a shell or docker executor.

sudo curl -fsSL https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb \
  -o /tmp/gitlab-runner.deb
sudo dpkg -i /tmp/gitlab-runner.deb
sudo gitlab-runner register \
  --non-interactive \
  --url http://<public-ip>/ \
  --registration-token <token> \
  --executor shell \
  --description "shared shell runner"

The Runner appears in the Runners list in the GitLab UI within a few seconds.

For any production GitLab deployment, serve the site over HTTPS so that passwords, Git push traffic and personal access tokens cannot be intercepted. The Omnibus package has built-in Let's Encrypt support that you toggle in /etc/gitlab/gitlab.rb.

The commands below assume that a DNS A record points your fully qualified domain name at the instance's public IP address.

sudo sed -i "s|^external_url .*|external_url 'https://gitlab.your-domain.example'|" /etc/gitlab/gitlab.rb
sudo tee -a /etc/gitlab/gitlab.rb >/dev/null <<'GLRB' letsencrypt['enable'] = true letsencrypt['contact_emails'] = ['admin@your-domain.example'] nginx['redirect_http_to_https'] = true GLRB
sudo gitlab-ctl reconfigure

GitLab's reconfigure step requests the certificate, installs it, switches nginx to HTTPS and schedules automatic renewal. Once the reconfigure finishes, the web UI is reachable at https://gitlab.your-domain.example/.

Back up two data sources together. The first is the application data: the embedded PostgreSQL database, the Git repositories, the uploads, the registry and the CI artifacts. The second is the server configuration and secrets in /etc/gitlab/.

The Omnibus gitlab-backup command bundles the application data into a single tarball under /var/opt/gitlab/backups/:

sudo gitlab-backup create
sudo tar -czf /var/backups/gitlab-config-$(date +%F).tgz -C /etc gitlab

Ship both archives to an Amazon S3 bucket or another object store. To restore, run gitlab-backup restore against an empty GitLab instance and unpack the /etc/gitlab tarball.

Ubuntu's unattended-upgrades is enabled on the deployed AMI, so kernel and package security patches apply automatically. To update GitLab itself, run sudo apt-get update && sudo apt-get install gitlab-ce to pull the latest version from the packages.gitlab.com repository. Then run sudo gitlab-ctl reconfigure.

For larger deployments, GitLab Omnibus lets you decouple individual subsystems while keeping the same all-in-one package on the application node:

• Move the embedded PostgreSQL to Amazon RDS for PostgreSQL and point Omnibus at it with gitlab_rails['db_host']
• Move the embedded Redis to Amazon ElastiCache for Redis with gitlab_rails['redis_host']
• Offload the GitLab container registry, CI artifacts and LFS objects to Amazon S3 by configuring the object storage settings under gitlab_rails['object_store']
• Place a load balancer in front of multiple GitLab application nodes, with shared Gitaly nodes for the Git repositories. Use an Application Load Balancer, or an AWS Network Load Balancer for the Git SSH traffic

Each of these patterns is documented in the official GitLab reference architectures at https://docs.gitlab.com/ee/administration/reference_architectures/.