Forging a Private Fortress: High-Performance Git Server Setup on Ubuntu 12.04

Let’s be honest for a second. If you are still dragging your team through Subversion (SVN) commits that take thirty seconds to complete because of network latency to a US-based server, you are bleeding productivity. The distributed nature of Git isn't just a trend; it's the new baseline for serious development. But here is the friction point: handing over your proprietary code to a public cloud provider like GitHub or Bitbucket often keeps CTOs awake at night.

Between the US Patriot Act and the stringent requirements of the Norwegian Personal Data Act (Personopplysningsloven), data sovereignty is not just a buzzword—it is a legal minefield. If you are developing in Oslo, Bergen, or Trondheim, your code should probably stay here. Furthermore, latency matters. The round-trip time (RTT) from Oslo to Amazon’s US-East facility is easily 100ms+. From your office to a CoolVDS server in Oslo? Likely under 5ms.

In this guide, we are going to build a rock-solid, private Git server using Ubuntu 12.04 LTS and Gitolite. We choose KVM virtualization (standard on CoolVDS) because OpenVZ containers often suffer from "noisy neighbor" syndrome that kills disk I/O performance during large merges.

The Hardware Baseline

Git is disk I/O intensive. When you have twenty developers doing a git fetch simultaneously, a standard SATA hard drive will choke. The seek times on mechanical drives are the bottleneck.

Pro Tip: Always verify your disk I/O before deploying a VCS. On CoolVDS, we utilize enterprise-grade SSDs in RAID 10. You can test your current server's write speed with: dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync. If you aren't seeing over 200 MB/s, move your hosting.

Step 1: Secure the Perimeter

Before we install a single binary, we secure the transport. We are using SSH, and we are disabling password authentication immediately. Brute-force bots scanning port 22 are relentless.

First, update your system repositories to ensure we aren't pulling ancient vulnerabilities:

sudo apt-get update && sudo apt-get upgrade -y

Next, configure your local machine (your laptop) to have an SSH key pair if you haven't already. Note that we use RSA 2048, as it is the current industry standard for compatibility.

# On your local machine, not the server
ssh-keygen -t rsa -b 2048 -C "admin@company.no"

Upload your public key to the CoolVDS instance:

scp ~/.ssh/id_rsa.pub root@your-coolvds-ip:/tmp/admin.pub

Step 2: The Git User and Gitolite

We do not want developers logging in as root. We will create a dedicated git user. This user handles the repositories and authenticates via SSH keys managed by Gitolite. Gitolite is essential because it allows you to manage access rights using a single configuration file committed to a repo—Infrastructure as Code, circa 2012 style.

# Install Git Core
sudo apt-get install git-core

# Create the git user
sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git

# Switch to the git user
sudo su - git

Now, we install Gitolite. We'll pull it directly from the source to ensure we have the latest v3 features, as the package repositories can be slightly behind.

# While logged in as the 'git' user
mkdir -p ~/bin

# Clone the Gitolite source
git clone git://github.com/sitaramc/gitolite

# Install the binaries
./gitolite/install -to ~/bin

# Setup the admin key (uploaded in Step 1)
~/bin/gitolite setup -pk /tmp/admin.pub

Step 3: Administration via Git

Here is where the magic happens. You do not log into the server to add users. You go back to your local workstation and clone the gitolite-admin repository. This puts the power of administration into the hands of your lead devs without giving them root shell access.

# On your LOCAL machine
git clone git@your-coolvds-ip:gitolite-admin
cd gitolite-admin

The directory structure is simple:

• conf/gitolite.conf: Defines your repositories and who can read/write to them.
• keydir/: Contains the .pub files for your developers (e.g., jens.pub, lars.pub).

To add a new repository for your team, edit conf/gitolite.conf:

repo    norwegian-project
        RW+     =   admin
        RW      =   jens lars
        R       =   external-auditor

Commit and push this change. Gitolite hooks on the server will instantly create the bare repository on the CoolVDS instance. It is seamless.

Performance Tuning for Large Repos

As your repository grows, Git's garbage collection can strain the CPU. On a shared host, this is where you get throttled. On a dedicated VDS, we can tune the memory usage. Since CoolVDS instances provide guaranteed RAM, we can be aggressive with Git's packing threads.

Edit the global git config on the server (/home/git/.gitconfig):

[core]
    packedGitWindowSize = 32m
    packedGitLimit = 256m
[pack]
    threads = 2
    windowMemory = 100m

This configuration prevents Git from consuming all available RAM during a git gc operation, ensuring the SSH daemon remains responsive even while the server is crunching data.

The Latency Advantage

Let’s look at the numbers. When your developers run git status or git blame, the operation is local. But git push and git fetch are network-bound. Here is a typical comparison for a user in Oslo:

That difference adds up. Over a year, your team saves hours simply by waiting less for network handshakes.

Compliance and Peace of Mind

By hosting on a CoolVDS server physically located in Norway, you simplify your compliance with the Datatilsynet guidelines. You know exactly where the physical drive resides. There is no ambiguous "cloud replication" to a jurisdiction with conflicting privacy laws. You control the keys, the firewall, and the data.

Don't let slow I/O or privacy concerns bottleneck your release cycle. Deploy a KVM-based, SSD-powered instance today and give your code the home it deserves.