Build a Bulletproof Private Git Server with CentOS 6 and Gitolite

Let’s get one thing straight: if your source code is the lifeblood of your company, why are you hosting it on a shared cloud server in Virginia? As a systems architect working in the Nordic market for over a decade, I've seen too many CTOs gloss over the US Patriot Act risks while focusing purely on feature sets.

Here in Norway, we operate under the Personopplysningsloven (Personal Data Act). While Safe Harbor exists, relying on it is a gamble I’m not willing to take with proprietary intellectual property. Plus, there is the physics argument: latency. If your team is coding in Oslo or Bergen, a round-trip packet to the US West Coast takes 150ms+. To a local VPS in Oslo? 5ms. That friction adds up every time you git push.

Today, I’m going to show you how to build a rock-solid, private Git server using CentOS 6 and Gitolite. No GUI bloat, no recurring licensing fees—just raw, efficient, secure version control.

Why Self-Hosted Git on KVM?

You might ask, "Why not just use GitHub?" In 2012, private repositories on GitHub get expensive fast as your team grows. More importantly, you don't own the infrastructure. When you deploy on a CoolVDS instance, you get KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ containers that oversell RAM and suffer from "noisy neighbors," KVM gives you a dedicated kernel and reserved resources.

Pro Tip: When compiling large projects or running heavy CI/CD hooks, I/O wait is the enemy. We use enterprise-grade RAID-10 SSD storage on our nodes to ensure your commit hooks don't hang while writing to disk. High I/O throughput is non-negotiable for development servers.

Step 1: Secure the Foundation

Start with a fresh CentOS 6.2 minimal install. Before we touch Git, we secure the perimeter. I’ve seen too many servers compromised by brute-force attacks on port 22.

# Update the system
yum update -y

# Create a dedicated git user
useradd -m -s /bin/bash git
passwd git

# Secure SSH
vi /etc/ssh/sshd_config

Inside your sshd_config, ensure you have the following set to prevent root logins and enforce protocol 2:

Protocol 2
PermitRootLogin no
AllowUsers git your_admin_user
PasswordAuthentication no

Restart SSH: service sshd restart. If you aren't using SSH keys yet, generate them now with ssh-keygen -t rsa -b 4096. Passwords are for amateurs.

Step 2: Install Git and Gitolite

The default repositories in CentOS 6 often carry older versions of Git. Let's ensure we have the EPEL (Extra Packages for Enterprise Linux) repository enabled to get a more recent version.

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
yum install git perl-Time-HiRes -y

Now, we install Gitolite. Gitolite is an access control layer on top of Git. It allows you to manage access to many repositories and users without creating actual Linux users for everyone. It’s the standard for serious teams.

Log in as the git user and clone the Gitolite source:

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

Step 3: Configuring Access

This is the clever part. You don't manage Gitolite on the server. You manage it from your workstation via a special admin repository. Upload your workstation’s public key (e.g., id_rsa.pub) to the server as /tmp/admin.pub.

Run the setup on the server:

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

Now, back on your local machine (your laptop), you can clone the admin repo:

git clone git@your-vps-ip:gitolite-admin

Inside, you will find a gitolite.conf file. This is where you define your team's access. It looks like this:

repo    cool-project
        RW+     =   alice
        R       =   bob
        R       =   deployment-bot

Commit and push this file, and Gitolite instantly reconfigures the server access controls. No service restarts required. This is true DevOps efficiency.

Optimization for High Loads

If your team is large, simple Git operations can stress the network stack. On CoolVDS, we optimize our Linux kernel parameters for low latency networking, specifically tuning for the Norwegian infrastructure (NIX).

Add these to your /etc/sysctl.conf to handle bursty traffic:

# Increase system file descriptor limit
fs.file-max = 65535

# Improve TCP handling
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

The Storage Reality: SSD vs HDD

In 2012, storage is usually the bottleneck. Traditional spinning rust (HDDs) can manage about 100-150 IOPS. When five developers pull large binary assets simultaneously, that drive queue spikes, and latency skyrockets.

At CoolVDS, we are aggressively moving to SSD storage solutions. While some call it a luxury, we consider it a baseline requirement for modern development environments. The random read/write speeds of solid-state drives mean your git status on a massive repo returns instantly, not in 3 seconds.

Conclusion

Setting up your own Git server allows you to sleep better at night. You know exactly where your data resides—on a server in Norway, protected by Norwegian law, not subject to foreign subpoenas. You eliminate per-user licensing fees, and with the right hardware, you outperform hosted solutions.

Don't let your development workflow be dictated by foreign latency or restrictive TOS. If you need a battle-tested platform for your code, we’ve prepared a specific CentOS 6 Developer Image on our platform.

Ready to take control? Deploy your KVM instance on CoolVDS today and experience the difference of local, high-performance hosting.