Centralized Git Hosting on Ubuntu 10.04: Building a Bulletproof Collaboration Hub in Norway

If I see one more developer email a tarball named project_final_v2_REAL.tar.gz, I might just pull the plug on the rack. It is 2010. Subversion (SVN) has served us well, but the era of distributed version control is here, and Git is the undeniable king. But here is the problem: public repositories like GitHub are fantastic for open source, but for proprietary code in the Norwegian enterprise sector, relying on US-hosted servers is a legal and latency nightmare.

I recently consulted for a dev team in Trondheim struggling with 300ms latency pushing to a server in California. Their productivity was bleeding out in the form of wait times. We moved their infrastructure to a local Linux VPS, dropped the latency to 12ms via NIX (Norwegian Internet Exchange), and their commit frequency tripled.

Today, we are going to build a production-ready Git server using Ubuntu 10.04 LTS (Lucid Lynx) and Gitolite. We will focus on security, raw performance, and why hosting this on the right hardware—like the setups we engineer at CoolVDS—is critical for data integrity.

Why Self-Hosted Git? (Beyond just "Because I Can")

It comes down to three factors: Latency, Control, and Compliance. Under the Norwegian Personal Data Act (Personopplysningsloven) and the watchful eye of Datatilsynet, you need to know exactly where your data lives. When you host on a CoolVDS KVM instance in Oslo, your code never leaves the jurisdiction. Plus, the US Patriot Act has made many European CTOs nervous about hosting intellectual property across the Atlantic.

Pro Tip: Don't underestimate disk I/O. Git operations, especially git gc (garbage collection) and repacking, hammer the disk. While standard SATA drives are fine for backups, your primary Git server needs the high IOPS found in Enterprise RAID-10 SAS or the emerging class of Enterprise SSDs available on high-end CoolVDS plans.

Step 1: The Environment & Security Prep

We are assuming you have a fresh CoolVDS VPS running Ubuntu 10.04. First, let's secure the box. We don't want unauthorized access to our intellectual property.

Login as root and update the system:

Next, install the essentials. We need Git, obviously, but also Perl for Gitolite:

Create a Dedicated Git User

Never run services as root. We create a system user specifically for handling Git requests. This user will not have a standard shell login, restricting them only to Git operations.

adduser --system --shell /bin/sh --gecos 'git version control' --group --disabled-password --home /home/git git

Step 2: Installing Gitolite for Granular Access Control

While you could just dump SSH keys into ~/.ssh/authorized_keys, that doesn't scale. You can't restrict which branches a user can push to. Enter Gitolite. It sits on top of Git and allows fine-grained access control without requiring system accounts for every developer.

Switch to the git user and clone the Gitolite source (Gitolite is not yet in the standard Lucid repos, so we install from source):

su - git
git clone git://github.com/sitaramc/gitolite
mkdir -p $HOME/bin
gitolite/install -to $HOME/bin

Now, you (the admin) need to authorize your workstation. On your local machine, generate an SSH key if you haven't already:

Copy this public key to your CoolVDS server:

Back on the server (as the git user), use this key to initialize Gitolite:

$HOME/bin/gitolite setup -pk /tmp/admin.pub

This command does the magic. It configures the authorized_keys file to force all connections through the Gitolite script. Now, access control is handled via a special Git repository called gitolite-admin.

Step 3: Managing Repositories "The DevOps Way"

You don't SSH into the server to add users anymore. You clone the admin repo, edit a text file, and push. This is Infrastructure as Code before it was a buzzword.

On your local machine:

git clone git@your-coolvds-ip:gitolite-admin
cd gitolite-admin
vim conf/gitolite.conf

Inside gitolite.conf, you define your teams. Let's say we have a project called "Vikings":

@devs = jens olav inger
@admins = admin

repo gitolite-admin
    RW+     =   admin

repo vikings
    RW+     =   @admins
    RW      =   @devs
    R       =   daemon

Commit and push this change. Gitolite immediately creates the "vikings" repository on the server and applies the permissions. It is seamless.

Performance Tuning for Large Monorepos

As your repository grows, Git performance can degrade if the server isn't tuned. If you are migrating a massive SVN history into Git, you will end up with large pack files.

Edit your /etc/sysctl.conf to optimize network stack for the high throughput expected on a CoolVDS line:

# Increase TCP max buffer size
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# Increase the number of incoming connections
net.core.somaxconn = 1024

Run sysctl -p to apply. Additionally, ensure your Git config manages memory wisely during repacks. In /home/git/.gitconfig:

[pack]
    windowMemory = 100m
    packSizeLimit = 100m
    threads = 1

Note: We limit threads to 1 here to avoid CPU stealing if you are on a crowded VPS node. However, on CoolVDS Dedicated KVM plans, you have guaranteed CPU cores, so you can increase this to match your core count for faster processing.

The Hardware Reality Check

You can configure software all day, but if the underlying disk is thrashing, your developers will complain. Git is essentially a filesystem-level database. Every git status checks file metadata.

Most budget hosts in Europe stuff hundreds of OpenVZ containers onto a single server with standard SATA 7.2k RPM drives. When one neighbor compiles a kernel, your Git operations stall. This is the "noisy neighbor" effect.

At CoolVDS, we use RAID-10 SAS arrays and are rolling out Enterprise SSD caching tiers. This means when you run a git clone of a 2GB repo, the read speeds are saturated by your network pipe, not the disk spindle. For a team of 20 developers pulling changes every morning, that difference is measured in hours of productivity per month.

Conclusion

Setting up a Git server on Ubuntu 10.04 gives you total sovereignty over your code. You comply with Norwegian privacy standards, you slash latency, and you avoid the licensing fees of proprietary solutions. But remember: a server is only as good as the metal it runs on.

Don't let I/O wait kill your development velocity. Deploy your Gitolite instance on a platform built for heavy workloads.

Ready to optimize your workflow? Deploy a high-performance CoolVDS Linux instance in Oslo today.