Controlling Your Code: Building a Bulletproof Private Git Server with Gitolite

Let’s be honest: trusting your company's intellectual property to a third-party cloud service in the US is a gamble. Sure, GitHub is convenient for open source, but when you are dealing with proprietary algorithms or sensitive customer data subject to the Norwegian Personal Data Act, you need to own the infrastructure. If the US government decides to seize a domain or a server farm goes dark, your team is dead in the water.

I recently audited a dev shop in Oslo struggling with SVN. They were pushing gigabytes of assets to a server in California. The latency was killing their productivity. A simple git push shouldn't give you enough time to brew a coffee. The solution? Bring the repo home. Host it on a robust VPS in Norway, minimize the hops to NIX (Norwegian Internet Exchange), and lock it down with RSA keys.

Here is how we build a secure, private Git server using Gitolite on CentOS 6. No web GUIs, no bloat—just raw performance and granular access control.

Why Gitolite and Not Just Plain SSH?

You could just create system users for every developer, but that is a security nightmare. You don't want junior devs having shell access to your production box. Gitolite sits on top of Git and uses a single system user (usually git) to manage access based on SSH keys. It allows you to define who can read, write, or rewind specific branches. It’s the industry standard for serious self-hosting right now.

The Infrastructure Requirement

Git creates a lot of small files and performs heavy I/O operations during garbage collection (git gc). Do not run this on cheap, oversold OpenVZ containers where you are fighting neighbors for disk time. You need guaranteed I/O.

At CoolVDS, we configure our virtualization stack to prioritize disk throughput. For a team of 10-20 developers, a standard slice with RAID 10 SAS storage provides the reliability and random write speeds required to prevent repo corruption during concurrent pushes.

Step 1: Server Prep and Dependencies

We will assume you are running a fresh install of CentOS 6. First, update your system and install Git. The default repositories might have an older version, so let's ensure we have the necessities.

Create a dedicated user for Git. This is the only user your developers will technically "connect" to.

Step 2: Installing Gitolite

Gitolite isn't in the standard yum repos, so we will install it from source. Switch to the git user and clone the source.

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

Now, you need to upload your workstation's public key (id_rsa.pub) to the server to initialize the admin access. Assume you uploaded it to /tmp/admin.pub.

Step 3: Configuration Management

Here is the beauty of Gitolite: you don't configure it by editing files on the server. You configure it by cloning a special admin repo to your local machine, editing a text file, and pushing it back. The server updates itself automatically via hooks.

On your local machine:

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

Add a new repo and define permissions:

repo    cool-project
        RW+     =   alice
        RW      =   bob
        R       =   intern_dave

Commit and push. That's it. Alice can force push (bad practice, but allowed), Bob can write, and Dave can only look. Total control.

Network & Security Optimization

Since this server holds your source code, it needs to be a fortress. Configure iptables to only allow SSH (port 22) from known IP ranges if your office has a static IP.

iptables -A INPUT -p tcp --dport 22 -s 123.45.67.89 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Pro Tip: If your team is distributed across Norway, latency to the server dictates the "snappiness" of Git. A ping of 150ms to a US server makes tab-completion over SSH painful. Hosting on CoolVDS in our Oslo facility typically yields 5-15ms latency for local ISPs, making remote terminal work feel like localhost.

Data Integrity and Backups

A Git server without backups is just a ticking time bomb. Use a simple cron job to rsync your repositories to a secondary location. Since Git objects are just files, rsync works perfectly, but ensure the repo is quiescent or use LVM snapshots if possible.

The Verdict

Hosting your own Git server on CentOS 6 gives you compliance with Datatilsynet data export regulations and removes the risk of third-party shutdowns. It requires a bit more command-line grease than a SaaS solution, but the control is absolute.

Don't let sluggish disk I/O corrupt your index files. Deploy your Gitolite instance on a CoolVDS Linux VPS today, where we treat disk latency as the enemy.