Stop the SVN Nightmare: Deploying a Private High-Performance Git Server in Norway

If I see one more developer email a tarball named project_final_final_v2.tar.gz, I might just pull the plug on the switch. It is 2010. We have moved past CVS. We are even moving past Subversion. Distributed Version Control Systems (DVCS) are the reality, and Git is the king of that hill.

But here is the problem affecting teams from Oslo to Trondheim: hosting. Sure, you could put your code on GitHub, but for many Norwegian enterprises, sending intellectual property to servers in the United States is a non-starter. Between the latency of crossing the Atlantic and the strict requirements of the Personopplysningsloven (Personal Data Act), serious development teams need a local solution.

You need your own Git server. You need it locally peered at NIX (Norwegian Internet Exchange) for instant pushes, and you need iron-clad control over who accesses what. Here is how we build a fortress for your code on a high-performance VPS.

The Latency Lie: Why Location Matters for Git

Git is fast, but network physics is immutable. When your developers run git clone on a 500MB repository hosted in San Francisco, they are at the mercy of transatlantic fiber. Packet loss and jitter turn a 2-minute clone into a coffee break.

Hosting your repository on a VPS in Norway cuts that latency from 140ms+ down to under 10ms. This isn't just about comfort; it's about the feedback loop. Faster clones mean faster builds, faster deployments, and less time staring at a blinking cursor.

Pro Tip: Network throughput is useless without disk I/O. Git performs thousands of small file operations during a checkout. Avoid standard SATA drives for your repo server. At CoolVDS, we utilize enterprise-grade RAID 10 SAS arrays (and are rolling out SSD caching) specifically to handle the high IOPS required by concurrent Git operations.

Step-by-Step: The "Gitosis" Architecture

We are going to use Ubuntu 10.04 LTS (Lucid Lynx), released just last month. It is stable, supported, and perfect for this. We will use Gitosis to manage access keys—because managing individual Unix user accounts for every developer is a maintenance nightmare you do not want.

1. The Foundation

First, spin up your CoolVDS instance. Do not skimp on RAM; Git needs memory for packing objects. 512MB is the bare minimum, but 1GB is recommended if you have a team larger than five.

Update your system immediately:

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

2. Install the Essentials

In Ubuntu 10.04, the package is still often referred to as git-core. We also need Python setup tools for Gitosis.

sudo apt-get install git-core python-setuptools

3. Create the Git User

This user will own the repositories. For security, this user should not have a password and should only be accessible via SSH keys.

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

4. Installing Gitosis

Gitosis isn't in the default repos yet, so we clone it and install from source. This is the "battle-hardened" way.

cd /tmp
git clone git://eagain.net/gitosis.git
cd gitosis
sudo python setup.py install

5. Initialize the Server

You need your local machine's public SSH key (e.g., id_rsa.pub) uploaded to the server to initialize Gitosis. Assume you uploaded it to /tmp/id_rsa.pub.

sudo -H -u git gitosis-init < /tmp/id_rsa.pub
# Make sure the post-update hook is executable
sudo chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update

Managing Access Like a Pro

Here is the beauty of this setup: You do not log into the server to add new developers. You manage access via Git itself.

On your local machine, you clone the admin repository:

git clone git@YOUR_COOLVDS_IP:gitosis-admin.git

Inside, you will find a gitosis.conf file and a keydir directory. To add a new developer, you simply:

1. Drop their public key into keydir/.
2. Edit gitosis.conf to add them to a group.
3. Commit and push.

Gitosis automatically updates the server's ~/.ssh/authorized_keys file. It is elegant, secure, and fully auditable.

Security & Data Sovereignty

By hosting this on a CoolVDS server in Oslo, you satisfy the Data Inspectorate (Datatilsynet) requirements regarding data location. Unlike cloud giants based in the US, your data sits on physical hardware within Norwegian jurisdiction.

However, a VPS is only as secure as you make it. Ensure you configure iptables to allow SSH (Port 22) only from trusted IP ranges if possible. Disable password authentication entirely in /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

Why Hardware Matters

Git creates high disk I/O when packing objects during garbage collection (git gc). On a shared hosting environment or a budget VPS where resources are oversold, this operation can hang the server. This is known as "CPU Steal," and it kills productivity.

At CoolVDS, we use Xen virtualization. Unlike OpenVZ, Xen provides true hardware isolation. Your RAM is your RAM. Your CPU cycles are reserved for you. When your team commits 50MB of assets simultaneously, the server doesn't choke.

Final Thoughts

Centralized version control is dead. But centralized management of your distributed code is vital. By deploying Gitosis on a high-performance Norwegian VPS, you get the best of both worlds: the speed of Git, the control of a private server, and the low latency of local hosting.

Your code is your business's most valuable asset. Don't host it on a slow, oversold box across the ocean. Spin up a CoolVDS instance today—setup takes less than 60 seconds—and give your development team the infrastructure they deserve.