Stop Leaking Your IP: The Case for a Private Git Server in Norway

If you are still emailing tarballs named project_final_final_v2.tar.gz, stop reading and go find a new career. If you are using Subversion (SVN) and complaining about merge conflicts, you have my sympathy, but it is time to move on. In 2012, Git is the only version control system that matters for serious distributed teams.

But here is the problem: relying on GitHub or Bitbucket means your proprietary code lives on servers in the US. For Norwegian companies, this introduces latency issues and potential compliance headaches with Datatilsynet (The Norwegian Data Protection Authority). Do you really want your intellectual property sitting under the Patriot Act jurisdiction when it could be sitting safely in Oslo?

I have seen too many teams suffer from 300ms latency on `git push` operations because they are routing traffic across the Atlantic. It breaks flow. It kills productivity. Today, we are going to build a rock-solid, private Git server using Gitolite on an Ubuntu 12.04 LTS instance. We will keep it local, fast, and under your control.

The Architecture: Why Latency and Disk I/O Matter

Git is fast, but it is effectively a filesystem content-tracker. When you run git gc (garbage collection) or handle large binary assets, your server's disk I/O takes a beating. Most budget VPS providers oversell their spinning hard drives (HDDs). The result? Your developers sit waiting for the server to repack objects.

Pro Tip: Never host a busy Git server on shared HDD storage. The "IO wait" will kill your CPU performance. At CoolVDS, we use enterprise-grade SSD arrays. While the industry is just starting to whisper about the upcoming NVMe storage specifications, we are already deploying the fastest PCIe-based flash storage available to ensure your git clone saturates the network link, not the disk controller.

Step 1: The Environment

We are using Ubuntu 12.04 LTS (Precise Pangolin). It is stable, supported until 2017, and has excellent package availability. Assume you have a fresh CoolVDS instance provisioned with a static IP.

First, update your system to ensure we aren't starting with security holes:

Step 2: Install Git and Create the User

We need the core git binaries. On Ubuntu 12.04, this gives us a stable 1.7.x release.

Now, create a dedicated system user for Git. This is a security best practice—never run services as root unless absolutely necessary.

Step 3: configuring Gitolite for Access Control

You could just use bare SSH keys, but managing access for a team of 10 developers becomes a nightmare of editing authorized_keys files manually. Enter Gitolite. It creates a virtualization layer for Git access control, allowing you to define permissions (Read/Write/Rewind) via a config file.

First, on your local machine (your laptop), generate an SSH keypair if you haven't already. This will be the "admin" key.

# On your LOCAL machine
ssh-keygen -t rsa -f ~/.ssh/git_admin

Copy the public key to your CoolVDS server:

# On your LOCAL machine
scp ~/.ssh/git_admin.pub root@:/tmp/git_admin.pub

Now, back on the server, install Gitolite. We will clone it from the source because the repo version is often outdated.

# Switch to the git user
su - git

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

# Create bin directory
mkdir -p $HOME/bin

# Install it
gitolite/install -to $HOME/bin

# Setup with the admin key
$HOME/bin/gitolite setup -pk /tmp/git_admin.pub

Step 4: Managing Your Repositories

This is where the magic happens. You don't log into the server to create repos anymore. You do it via Git itself. Go back to your local machine.

Add the following to your local ~/.ssh/config to make life easier:

Host git-server
    HostName 
    User git
    IdentityFile ~/.ssh/git_admin

Now, clone the admin repository:

You will see a folder structure like this:

gitolite-admin/
├── conf/
│   └── gitolite.conf
└── keydir/

Adding a New Developer and Repository

To add a developer named "Lars", put his public SSH key into keydir/lars.pub. Then, edit conf/gitolite.conf:

repo gitolite-admin
    RW+     =   git_admin

repo testing
    RW+     =   @all

repo nordic-project
    RW+     =   git_admin
    RW      =   lars
    R       =   deploy_bot

Commit and push these changes. Gitolite's hooks will automatically configure the server, create the nordic-project.git bare repository, and update the SSH keys. No server login required.

Network Performance: The NIX Connection

Why bother hosting this on a VPS in Norway? Latency. The Norwegian Internet Exchange (NIX) in Oslo ensures that traffic between your ISP (Telenor, Altibox, etc.) and your server stays within the country. This results in ping times as low as 2-5ms.

When you are running a git blame on a massive history or cloning a 2GB repository, that low latency combined with high throughput is noticeable. Standard cloud providers route you through Frankfurt or London, adding 30-50ms overhead per packet.

Security Hardening

Before you go live, harden the SSH daemon. Edit /etc/ssh/sshd_config on your server:

PasswordAuthentication no
PermitRootLogin no
AllowUsers git

This ensures that only key-based authentication is allowed, and nobody can brute-force the root password. In the world of managed hosting, security is a shared responsibility, but locking down SSH is 100% on you.

Conclusion

You now have a secure, private Git infrastructure that complies with Norwegian data handling norms and outperforms overseas hosting significantly. No monthly per-user fees, no uncertain data jurisdictions, just raw performance.

Building this on CoolVDS means you are backed by high-speed storage that handles thousands of IOPS without breaking a sweat, ensuring your git status never hangs. Don't let slow I/O kill your workflow.

Ready to take control of your code? Deploy a high-performance SSD VPS on CoolVDS in 55 seconds.