Derek Coleman & Associates Inc logoDerek Coleman & Associates Inc

Home / Support / GitLab CE on Ubuntu 24.04 LTS

GitLab CE on Ubuntu 24.04 LTS — Support & Quick Start

GitLab Community Edition DevOps platform on Ubuntu 24.04 LTS — Git hosting, CI/CD, and registry in your own subscription.

Fixed on image version 2026.916.1357 (published 2026-09-16)

The initial `gitlab-ctl reconfigure` moved from build time to first boot: it seeds a fresh per-VM root password, writes it to /etc/gitlab/initial_root_password (root-only) and verifies the root sign-in before the VM reports ready. `sudo cat /etc/gitlab/initial_root_password` now works as the listing documents.

If you deployed this VM before 2026-09-16, it came from the older image and is not changed by the new publication — redeploy from the current Marketplace version, or apply the one-time repair below:

  1. On a VM from an earlier image that file does not exist (GitLab deletes it 24 hours after the reconfigure, which had already run at build time). Set the root password yourself with GitLab's documented reset — it prompts twice for a new password and takes about a minute — then sign in at http://<VM-IP>/users/sign_in as root.
sudo gitlab-rake "gitlab:password:reset[root]"

Image change: see the pull request.

Source: the Marketplace live version set for this offer, read from Partner Center on 2026-09-16. New deployments take the newest version by default.

At a glance

Application ports80 (HTTP), 443 (HTTPS once you configure a certificate); Git over SSH uses the VM's port 22
Open in browserhttp://<VM-IP>/
Admin credential filesudo cat /etc/gitlab/initial_root_password
Sign in asroot
Service(s)gitlab-runsvdir (Omnibus: `sudo gitlab-ctl status`)
Configuration/etc/gitlab/gitlab.rb (external_url is re-pointed at the VM's address at first boot; run `sudo gitlab-ctl reconfigure` after edits)
Logs/var/log/gitlab/ (`sudo gitlab-ctl tail`)
VersionGitLab CE (Omnibus package, current at build)
PlatformUbuntu 24.04 LTS

Quick start

  1. Deploy from the Azure Marketplace (Get It Now → Create), choosing your SSH key at the Administration step.
  2. Allow inbound SSH (22) for yourself plus the application port(s): 80 (web) and 443; 22 for Git over SSH — restrict to your own IP where possible. The in-image firewall already allows them; only the Network Security Group (NSG) keeps them closed.
  3. Wait for the first-boot reconfigure, print the generated root password with `sudo cat /etc/gitlab/initial_root_password`, then open http://<VM-IP>/ and sign in as root (see First login below).
  4. Set your real external_url (with https://) in /etc/gitlab/gitlab.rb, run `sudo gitlab-ctl reconfigure`, then add users and your first project.

First login / credentials

This image generates its admin credential on the VM at first boot — nothing is pre-set. SSH into the VM with the username + key you chose at deploy, then print the generated credential:

ssh <your-username>@<VM-IP>
sudo cat /etc/gitlab/initial_root_password

Sign in as root.

  1. First boot runs the initial `gitlab-ctl reconfigure` on YOUR VM — allow several minutes before http://<VM-IP>/ answers (`sudo gitlab-ctl status` shows every service `run:`).
  2. Print the generated root password: `sudo cat /etc/gitlab/initial_root_password`. It is unique to this VM, seeded by that first reconfigure and proven against the running server before first boot reports done. GitLab removes the file 24 hours after the reconfigure, so read it on day one.
  3. Open http://<VM-IP>/users/sign_in and sign in as root, change the password immediately, then add your users and first project.
  4. Deployed this VM before 2026-09-16? That image reconfigured at build time, so the file is already gone — set the password yourself with `sudo gitlab-rake "gitlab:password:reset[root]"` (it prompts twice and takes about a minute).

Sign in as root with the password in /etc/gitlab/initial_root_password, then change it. The file is root-only and GitLab removes it 24 hours after the first reconfigure — read it on day one. On VMs deployed before 2026-09-16 the file is absent: use `sudo gitlab-rake "gitlab:password:reset[root]"` instead.

Still stuck?

Email support@dcassociatesgroup.com (response within 1 business day) or send a message via the contact form. Include the offer name, VM size, region, and any log output — sudo journalctl -u <service> -n 100 usually tells the story.