Latency is the Enemy of Code
I recently watched a developer spend four minutes waiting for a git clone to finish from a repository hosted on the US West Coast. In our line of work, that friction isn't just annoying; it breaks the flow. If you are building software in Oslo or Trondheim, routing your intellectual property through a server 8,000 kilometers away is technically inefficient and, frankly, a liability.
While GitHub is excellent for open source, closed-source enterprise development requires tighter control. You need granular access management, absolute data sovereignty under the Norwegian Personal Data Act (Personopplysningsloven), and single-digit millisecond latency. You don't get that sharing a spindle with ten thousand other users in Virginia.
Today, we are going deep on setting up a battle-ready, private Git server using Gitolite on a dedicated CoolVDS instance. We aren't just installing packages; we are architecting a collaboration hub that respects your uptime.
The Architecture: Why Gitolite?
You might ask, "Why not just raw SSH?" Because managing shell accounts for 20 developers is a security nightmare waiting to happen. Gitolite sits on top of Git and allows you to define permissions using a simple configuration file. It uses a single system user (usually git) but differentiates developers via their public SSH keys.
Hardware Requirements
Git is I/O intensive. When your team hits a deadline and everyone is running git status, git diff, and pushing objects simultaneously, standard 7.2k RPM hard drives will choke. I/O wait creates load, and load kills responsiveness.
Pro Tip: Never cheap out on storage for version control systems. We use CoolVDS instances backed by Enterprise SSDs. The random read/write speeds of Solid State Drives compared to traditional spinning disks mean your large rebases happen in seconds, not minutes. If your VPS provider is still selling you "large storage" on SATA drives for a repo server, run away.
Step 1: The Base Build
We will use Ubuntu 10.04 LTS (Lucid Lynx). It is rock stable. Assume you have a fresh CoolVDS instance provisioned.
First, update your repositories and install the essentials. We need Git and SSH.
root@oslo-node:~# apt-get update && apt-get upgrade -y
root@oslo-node:~# apt-get install git-core openssh-server
Step 2: Securing the Environment
Before we touch Git, we secure the door. Create a dedicated git user. This isolates the repositories from the rest of the system.
root@oslo-node:~# adduser --system --shell /bin/bash --group --disabled-password --home /home/git git
Next, copy your local workstation's public key (usually ~/.ssh/id_rsa.pub) to the server. You will need this to initialize Gitolite as the administrator.
# On your local machine
scp ~/.ssh/id_rsa.pub root@your-coolvds-ip:/tmp/admin.pub
Step 3: Installing Gitolite
Gitolite isn't in the default Lucid repos yet, so we install from source. This ensures we have the latest hooks and config options. Switch to the git user and clone the Gitolite source.
root@oslo-node:~# su - git
git@oslo-node:~$ git clone git://github.com/sitaramc/gitolite
git@oslo-node:~$ mkdir -p $HOME/bin
git@oslo-node:~$ ./gitolite/install -to $HOME/bin
git@oslo-node:~$ ./bin/gitolite setup -pk /tmp/admin.pub
If you see no errors, Gitolite is live. It has created a gitolite-admin repository. You can now delete the key from /tmp.
Step 4: Administration Workflow
Here is the beauty of this setup: You never SSH into the server to add users again. You manage the server using Git.
Back on your local machine, clone the admin repo:
git clone git@your-coolvds-ip:gitolite-admin.git
cd gitolite-admin
Inside, you will find two directories: conf/ and keydir/.
- To add a user: Drop their public key (e.g.,
johndoe.pub) intokeydir/. - To create a repo: Edit
conf/gitolite.conf.
An example config for a new Norwegian project:
repo nordic-project-x
RW+ = admin
RW = johndoe
R = consultant-alice
Commit and push these changes. Gitolite's hooks will automatically update the server configuration. It is clean, audit-friendly, and scriptable.
Performance Tuning & Norway Specifics
Because your CoolVDS instance is located in Oslo, your latency to the Norwegian Internet Exchange (NIX) is likely under 2ms. However, network speed means nothing if your TCP stack is unoptimized.
Edit your /etc/sysctl.conf to handle bursty traffic common with Git pushes:
# Prevent TIME_WAIT issues under load
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
# Increase buffer sizes for high-speed connections
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
Reload with sysctl -p.
The Verdict
Self-hosting Git gives you sovereignty. When Datatilsynet comes knocking about where your customer data resides, you can point to a physical rack in Oslo, not a nebulous cloud diagram.
But remember, a server is only as good as the hardware beneath it. Virtualization overhead (CPU steal time) can ruin the responsiveness of Git commands. This is why we rely on CoolVDS's Xen-based architecture; guaranteed resources mean your compile times stay consistent.
Stop tolerating latency. Spin up an SSD-powered instance today and give your team the infrastructure they deserve.