How to Set Up a GitLab Server on Windows Server with Hyper-V

To set up GitLab Self-Managed on Windows Server, run a supported Ubuntu Server virtual machine in Hyper-V and install GitLab inside the Linux guest. Windows Server remains the host; GitLab runs from its official Linux package. GitLab’s current Ubuntu package guide lists Ubuntu 22.04 and 24.04, so this walkthrough uses Ubuntu Server 24.04 LTS.

Before you begin, confirm the host can spare CPU, RAM, and disk for the guest. GitLab’s single-node baseline is 8 vCPUs and 16 GB RAM; budget 40 GB for the application, 5–12 GB for the database, plus repository storage. Use SSD-backed disks and leave resources for Windows Server.

1. Install the Hyper-V role

In Server Manager, choose Manage > Add Roles and Features, select the local server, and enable Hyper-V. Include the management tools and allow the required restart. You can also run PowerShell as an administrator and install the local role with:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

Hyper-V installation restarts the host. Check Microsoft’s Hyper-V installation guide if your server uses a different management setup.

2. Create a virtual switch for the guest

In Hyper-V Manager, open Virtual Switch Manager and create an External switch on the host’s LAN adapter. Choose whether Windows should share it. This gives Ubuntu a LAN address and lets authorized devices reach GitLab. Use a trusted LAN or VPN; follow your network policy before public access. See Microsoft’s virtual switch guide.

3. Create the Ubuntu virtual machine

Download Ubuntu Server 24.04 LTS. In Hyper-V Manager, create a VM named GitLab-Ubuntu, choose Generation 2, connect the external switch, and create an SSD-backed VHDX. Use GitLab’s 8-vCPU/16-GB baseline for a single node; a lab can start smaller, with slower performance.

Attach the ISO to the virtual DVD drive. If Ubuntu does not boot, set the Generation 2 VM’s Secure Boot template to Microsoft UEFI Certificate Authority.

4. Install Ubuntu and give it a stable address

Start the VM and complete the Ubuntu Server installer. Create an administrator account, use a hostname such as gitlab, and enable OpenSSH for remote administration. Give the VM a static IP or DHCP reservation so its address stays stable.

After the first login, install available updates and restart if prompted:

sudo apt update && sudo apt upgrade -y

5. Set DNS and allow only the required traffic

Create a DNS record such as gitlab.example.com that resolves to the VM’s stable address. Allow inbound TCP ports 22 for Git over SSH, 80 for HTTP and Let’s Encrypt certificate validation, and 443 for HTTPS. Apply matching rules in Ubuntu’s firewall, the Windows/network firewall, and any router or cloud firewall in front of the host. Restrict SSH and web access to intended users or networks where possible.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

6. Install the GitLab Linux package

These commands install the Community Edition package. Replace the example hostname with the DNS name you configured. For Enterprise Edition, use the EE option in GitLab’s official Ubuntu installation guide. Review the repository setup script before running it as an administrator.

sudo apt update
sudo apt install -y curl
curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

With a valid public DNS name and inbound HTTP access, GitLab can request a Let’s Encrypt certificate during installation. For an internal-only server, configure a certificate trusted by your organization and follow GitLab’s current TLS instructions. Check the GitLab installation requirements before sizing a production VM.

7. Sign in, secure the instance, and test a repository

When installation finishes, open https://gitlab.example.com. Sign in as root; retrieve the initial password from /etc/gitlab/initial_root_password on the Ubuntu VM. GitLab removes that file after 24 hours, so change the password immediately and store the new credential securely.

Create a test project, add a README, and clone it over HTTPS or SSH from a client machine to confirm DNS, firewall rules, and authentication work. Before inviting a team, review GitLab’s recommended next steps, enable two-factor authentication, and restrict public sign-ups if the instance is private. Configure scheduled backups and copy them off the VM; the GitLab backup guide explains what the backup command includes and what must be backed up separately.

Keep Windows and Ubuntu patched, watch disk growth, and test a backup restore before relying on the instance for important repositories.