Gitblit on Ubuntu 24.04 on Azure User Guide

Overview

Gitblit is an open-source, pure-Java Git server. It hosts repositories over HTTP, HTTPS, SSH and the git protocol, provides a web interface for browsing commits, branches and files, and includes an admin panel with its own flat-file user and permission model — no external database. The cloudimg image installs Gitblit 1.10.0 on OpenJDK 17 at /opt/gitblit, runs it as a dedicated gitblit system user with its data at /var/lib/gitblit, binds the application to loopback and fronts it with an nginx reverse proxy that terminates a per-VM TLS certificate on :443, and generates a unique admin password, TLS certificate and SSH host key on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• Gitblit 1.10.0 Git server on OpenJDK 17 at /opt/gitblit, data at /var/lib/gitblit
• nginx reverse proxy terminating a per-VM self-signed TLS certificate on :443, in front of Gitblit on loopback :8080
• Git over HTTPS (:443) and Git over SSH (Gitblit's built-in daemon on :29418)
• Authenticated-only access by default — every repository requires a sign-in to view, clone or push
• Per-VM admin password (GITBLIT_ADMIN_PASSWORD) generated at first boot, in a root-only file, with the stock admin/admin default removed
• Per-VM TLS certificate and per-VM Gitblit SSH host key generated at first boot
• gitblit.service + nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a solid starting point; scale up for many concurrent users or large repositories. NSG inbound: allow 22/tcp from your management network, 443/tcp for the web UI and Git-over-HTTPS, and — if you use Git-over-SSH — 29418/tcp, from the networks that need them.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Gitblit by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Then Review + create → Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name gitblit \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name gitblit --port 443 --priority 1010

Step 3 — Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 — Confirm the services are running

systemctl is-active gitblit.service nginx.service

Both services report active. Gitblit can take up to a minute to fully start on first boot while the JVM warms up and generates its per-VM SSH host key.

Step 5 — Retrieve your admin password

The admin password is generated uniquely on the first boot of your VM and written to a root-only file. The stock admin/admin default is removed at build time and never ships.

sudo cat /root/gitblit-credentials.txt

The GITBLIT_ADMIN_PASSWORD value is the password; sign in to the web UI as admin with it.

Step 6 — Sign in to the web UI

Browse to https://<vm-public-ip>/ and sign in as admin with the password from Step 5. The certificate is self-signed and unique to this VM, so your browser shows a one-time warning — accept it, or install a CA-signed certificate (see Using your own TLS certificate below). Because the appliance is authenticated-only, an unauthenticated visitor sees only the sign-in prompt.

After signing in you land on your dashboard, which lists your repositories and recent activity.

Step 7 — Create your first repository

Click repositories → create repository, give it a name (for example myrepo), and save. Alternatively, Gitblit creates a repository automatically the first time an admin pushes to a new URL (see Step 8). Once it has content you can browse its commit history, branches and files directly in the web UI.

Step 8 — Clone and push over HTTPS

From your workstation, clone over HTTPS and authenticate as admin. Because the certificate is self-signed, either install it as trusted or set GIT_SSL_NO_VERIFY=true for that clone:

git -c http.sslVerify=false clone https://admin@<vm-public-ip>/r/myrepo.git

To verify the full round-trip on the VM itself — create a repository by pushing to a new URL (Gitblit creates it on first push), then clone it back — run:

PW=$(sudo grep '^GITBLIT_ADMIN_PASSWORD=' /root/gitblit-credentials.txt | cut -d= -f2-)
REPO="guide-demo-$(date -u +%s)"
WK=$(mktemp -d); cd "$WK"
git -c init.defaultBranch=master init -q app && cd app
printf '# %s\n' "$REPO" > README.md
git -c user.email=you@example.com -c user.name=you add README.md
git -c user.email=you@example.com -c user.name=you commit -qm "Initial commit"
git -c http.sslVerify=false push "https://admin:$PW@127.0.0.1/r/${REPO}.git" master
cd "$WK"
git -c http.sslVerify=false clone -q "https://admin:$PW@127.0.0.1/r/${REPO}.git" verify
grep -q "$REPO" verify/README.md && echo "ROUND_TRIP_OK: pushed commit is present after re-clone"

Step 9 — Use Git over SSH (optional)

Gitblit runs its own SSH daemon on :29418. In the web UI open your profile → edit → add SSH key and paste your public key, then clone using the SSH URL shown on each repository's summary page:

git clone ssh://admin@<vm-public-ip>:29418/myrepo.git

The SSH host key is unique to your VM (generated on first boot), so the first connection prints a normal host-key confirmation.

Access model and opt-in to public read

The appliance ships authenticated-only: git.defaultAccessRestriction = VIEW means every repository requires a sign-in to view, clone or push, and web.authenticateViewPages = true means the web UI shows nothing to anonymous visitors. To allow anonymous (public) read of repositories, edit /var/lib/gitblit/gitblit.properties and set the global default, or set it per-repository in the web UI's repository settings, then restart Gitblit:

# Allow anonymous clone/read globally (opt-in):
git.defaultAccessRestriction = PUSH
web.authenticateViewPages = false

Manage users, teams and per-repository permissions from users and each repository's edit → permissions panel.

Using your own TLS certificate

The image generates a per-VM self-signed certificate at /etc/ssl/gitblit/. For production, point a domain at the VM and install a CA-signed certificate — for example with certbot (replace the domain), then reload nginx:

sudo apt-get update && sudo apt-get install -y certbot
sudo certbot certonly --standalone -d your-domain.example.com
sudo sed -i 's#/etc/ssl/gitblit/gitblit.crt#/etc/letsencrypt/live/your-domain.example.com/fullchain.pem#; s#/etc/ssl/gitblit/gitblit.key#/etc/letsencrypt/live/your-domain.example.com/privkey.pem#' /etc/nginx/sites-available/cloudimg-gitblit-ssl
sudo systemctl reload nginx

Backup and maintenance

All repositories, configuration and the flat-file user database live under /var/lib/gitblit — snapshot the OS disk in Azure to back it up. Keep the OS patched with sudo apt update && sudo apt upgrade. Gitblit restarts cleanly with sudo systemctl restart gitblit, and its configuration is in /var/lib/gitblit/gitblit.properties.

Support

This image is backed by 24/7 cloudimg support. Contact us by email and chat for help with repository hosting, user and permission management, Git-over-SSH, TLS and backups.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them. Git is a trademark of the Software Freedom Conservancy.