Hosting Your Own Git Infrastructure: Speed, Security, and Sanity
If I have to resolve one more Subversion (SVN) tree conflict because two developers touched the same XML config file, I am going to pull the power cord on the rack. It is 2010. Centralized version control is obsolete. If your team is still afraid of branching because merging is a nightmare, you are bleeding money and efficiency.
The industry is moving to Git. Linus Torvalds gave us the kernel, and then he gave us the tools to manage it. But here is the problem: public hosting like GitHub is great for open source, but for proprietary commercial code? You want that data on metal you control. You don't want your intellectual property sitting on a server in San Francisco subject to the US Patriot Act, and you certainly don't want the latency involved in pushing 500MB of binary assets across the Atlantic.
For Norwegian development teams, data sovereignty is not just a buzzword; under the Personopplysningsloven (Personal Data Act), knowing exactly where your data lives is critical. Plus, pushing code to a server in Oslo (like those provided by CoolVDS) versus a server in Virginia is the difference between an instant push and a coffee break.
Today, we are going to build a private, secure Git server using Ubuntu 10.04 LTS (Lucid Lynx) and Gitolite. No GUI bloat, no monthly per-user fees—just raw SSH performance.
The Hardware: Why I/O Matters
Git is incredibly fast, but it is I/O intensive. When you have ten developers cloning a repo simultaneously, your disk heads are thrashing. Most cheap VPS providers oversell their storage arrays. You end up with "noisy neighbors" stealing your IOPS.
Pro Tip: Do not run a Git server on shared hosting or OpenVZ containers where you can't control the kernel. You want KVM virtualization or Xen. At CoolVDS, we use strict KVM isolation with RAID-10 SAS arrays. This ensures that when you run git gc (garbage collect) on a massive repo, the server doesn't choke. Stability is not an accident; it is an architecture choice.
Step 1: Server Preparation
I assume you have a fresh instance of Ubuntu 10.04 LTS. First, let's secure the basics and update our repositories. Never deploy a server without patching it first.
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install python-software-properties
Set up a dedicated user for Git. Do not run this as root. If you run services as root, you deserve to get hacked.
sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git
Step 2: Installing Git and Gitolite
We need the core Git binaries. In Lucid Lynx, the package is git-core.
sudo apt-get install git-core openssh-server
Now, for the access control. We could just use standard UNIX permissions, but that gets messy when you have 50 developers and 200 repositories. We are going to use Gitolite. It sits on top of SSH and allows you to define permissions (read, write, force-push) via a simple configuration file.
Log in as the git user and grab the Gitolite source. We are compiling from source because the repo packages are often outdated.
# Switch to the git user
sudo su - git
# Create a bin directory
mkdir ~/bin
# Clone the Gitolite source code
git clone git://github.com/sitaramc/gitolite
# Install it
gitolite/src/gl-system-install
Step 3: The Admin Key Setup
This is where most people trip up. Gitolite uses a specific SSH key to identify the administrator. You need to generate a key pair on your local workstation (not the server) and upload the public key.
On your local machine:
ssh-keygen -t rsa -f ~/.ssh/git_admin
scp ~/.ssh/git_admin.pub root@your-coolvds-ip:/tmp/git_admin.pub
Back on the server (as the git user):
# Run the setup script with the public key
gl-setup /tmp/git_admin.pub
You should see output indicating that the .ssh/authorized_keys file has been populated. Gitolite now manages this file. DO NOT EDIT IT MANUALLY, or you will break everything.
Step 4: Managing Repositories
Here is the beauty of Gitolite: you don't log into the server to create new repositories. You administer the server by pushing changes to a special git repository called gitolite-admin.
Back on your workstation, add the config to your ~/.ssh/config file to make life easier:
Host git-server
HostName your-coolvds-ip
User git
IdentityFile ~/.ssh/git_admin
Now clone the admin repo:
git clone git-server:gitolite-admin
cd gitolite-admin
Inside, you will find two directories: conf/ and keydir/. To add a new user, simply drop their public key (e.g., johndoe.pub) into keydir/.
To create a new repository and give John access, edit conf/gitolite.conf:
repo project-omega
RW+ = admin
RW = johndoe
R = deploy-bot
Commit and push:
git add .
git commit -m "Added Project Omega and user John"
git push
Gitolite's hooks will run on the server, create the new repository on the filesystem, and update the SSH keys automatically. It’s magic. It scales. It works.
Performance Tuning for High Load
If you are migrating a massive SVN repo to Git, the initial clone can be heavy. On a standard VPS, you might run out of RAM if Git tries to pack too many objects at once. This is why we configure git config to be respectful of memory limits.
On the server (as git user), edit ~/.gitconfig:
[core]
packedGitWindowSize = 32m
packedGitLimit = 256m
[pack]
windowMemory = 256m
threads = 1
This ensures that a single aggressive clone operation doesn't send your server into swap death. If you are on a CoolVDS high-memory plan, you can increase these limits, but on a standard 512MB or 1GB slice, keep it tight.
Why Location Matters
Let's talk about latency. If your office is in Oslo or Bergen, and your Git server is in Texas, every SSH handshake has a 140ms overhead. That doesn't sound like much until you are doing a git status against a large remote or running an automated deployment script that opens 50 connections.
| Metric | US Hosting (East Coast) | CoolVDS (Norway/Europe) |
|---|---|---|
| Ping Latency (from Oslo) | ~120-150ms | ~5-15ms |
| Throughput (Git Push) | Fluctuates over Atlantic | Consistent, low-hop routing |
| Data Jurisdiction | US Patriot Act | Norwegian/EEA Law |
By hosting on CoolVDS, you are keeping the traffic local at the NIX (Norwegian Internet Exchange). Your git pull feels instant.
Final Thoughts
You don't need a bloated GUI to manage code. You need a file system, an SSH daemon, and a solid permission manager like Gitolite. This setup is auditable, secure, and complies with strict internal data policies.
Don't let your infrastructure be the bottleneck. Code moves fast; your server should too. If you're ready to set this up, deploy a CoolVDS instance today—our KVM slices are provisioned in under 60 seconds.