Stop Trusting Third Parties with Your IP: The Case for Self-Hosted Git
If you are still using Subversion (SVN) in 2011, you are actively choosing to suffer. The centralized model is dead. It died the moment distributed version control systems (DVCS) proved that branching shouldn't be a painful, weekly ritual that brings the entire dev team to a halt. But moving to Git often leads teams to a crossroads: pay a premium for private GitHub repositories hosted on US servers, or roll up your sleeves and host it yourself.
As a sysadmin who has spent the last week migrating a Magento codebase from a failing SVN repo, I can tell you: own your infrastructure. Relying on external services introduces latency that kills productivity. When you push 500MB of assets to a server in San Francisco from an office in Oslo, you feel every millisecond of that round-trip time. It breaks the flow.
This guide covers setting up a battle-ready Git server using Gitolite on CentOS 6. We choose CentOS for its stability and long-term support cycle—crucial when you don't want to upgrade your primary repo server every six months.
The Latency Problem: Physics vs. Your Deadline
Why host in Norway? Physics. Light has a speed limit. Ping times from Oslo to US West Coast data centers often hover around 160-200ms. If your developers are doing dozens of `git fetch` and `git push` operations daily, that lag compounds. By hosting on a local VPS, like a CoolVDS instance peering directly at NIX (Norwegian Internet Exchange), you drop that latency to sub-10ms. The console feels instant.
Pro Tip: Don't skimp on I/O. Git is essentially a filesystem map. Heavy operations like `git gc` (garbage collection) will hammer your disk. While traditional SATA drives are fine for backups, your primary repo server needs the random read/write speeds of enterprise SSDs or a 15k RPM SAS RAID 10 array. CoolVDS standardizes on high-performance storage for this exact reason—waiting for disk I/O is wasted billable hours.
Step 1: The Environment
We assume you are running a fresh install of CentOS 6.0 or 5.6. First, secure the box. Since this holds your intellectual property, standard password authentication is unacceptable.
# On your local machine, generate a key pair if you haven't already
ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"
Log into your VPS and disable password login in /etc/ssh/sshd_config after you have added your public key. This is non-negotiable.
PasswordAuthentication no
PermitRootLogin without-password
Step 2: Install Git and Gitolite
CentOS repositories can be a bit behind the bleeding edge. As of August 2011, Git 1.7.x is the target. If the base repo version is too old, compile from source. For this guide, we will use the standard EPEL repositories which usually provide a stable enough version.
yum install epel-release
yum install git perl-Time-HiRes
Now, create a dedicated user for Git. This user will manage all repositories. Do not run this as root.
useradd -m git
passwd -l git
The Gitolite Setup
Gitolite allows you to manage access control via a configuration file in a special Git repository. It's much lighter than Gitorious and doesn't require a heavy Ruby stack setup.
Transfer your local workstation's public key (id_rsa.pub) to the server's /tmp directory, renaming it to your username, e.g., admin.pub.
# Login as the git user
su - git
# Clone the Gitolite source code
git clone git://github.com/sitaramc/gitolite
# Install it to the bin directory
gitolite/src/gl-system-install
# Setup the initial admin
gl-setup /tmp/admin.pub
If you see a warning about $PATH, verify that /usr/local/bin is in your path. Once the setup script finishes, you have a functioning server.
Step 3: Managing Access (The "Magic" Part)
Here is where Gitolite shines. You don't manage users by logging into the server anymore. You manage them via Git. Back on your local machine:
git clone git@your-coolvds-ip:gitolite-admin
cd gitolite-admin
You will see two directories: conf and keydir.
- keydir: Drop your developers' public keys here (e.g.,
jens.pub,lars.pub). - conf/gitolite.conf: define permissions.
Edit the config file to add a new repository:
repo internal-api
RW+ = admin
RW = jens
R = lars
Commit and push these changes. Gitolite's hooks immediately update the server-side permissions. Jens can push code. Lars can only read it. No sudo required, no Linux user management mess.
Data Sovereignty and Compliance
In Norway, we adhere to the Personopplysningsloven (Personal Data Act). While code isn't always personal data, the databases usually included in your dev environments often are. Storing this data on US servers (AWS, GitHub) puts you under the jurisdiction of the US Patriot Act.
By keeping your Git server on a Norwegian VPS, you simplify compliance. You know exactly where the drives are spinning. CoolVDS infrastructure is located in secure facilities that respect EU data directives. Don't let a legal gray area become a technical debt.
Performance Tuning
Linux defaults are often conservative. For a Git server handling large binaries or heavy CI traffic (if you are hooking this up to Jenkins), tweak your sysctl.conf:
# Improve network handling for many small connections
net.ipv4.tcp_tw_reuse = 1
net.core.somaxconn = 1024
Furthermore, ensure you have plenty of RAM cached. Linux loves to cache filesystem inodes. If you are running on a budget VPS with 512MB RAM, you will hit swap during a large clone operation. We recommend a minimum of 2GB RAM for a team of 5-10 developers to keep the index in memory.
Conclusion
Distributed version control is the present and future. But "distributed" doesn't mean "hosted by strangers." By spending 20 minutes configuring Gitolite on a robust CentOS slice, you gain total control, better security, and significantly lower latency for your local team.
Don't let slow I/O or network lag throttle your development speed. Deploy a high-performance SSD VPS on CoolVDS today and experience what Git is actually supposed to feel like.