Taking Control of Your Code: Private Git Hosting in the Post-Patriot Act Era
Let's be honest: relying on GitHub for proprietary commercial code is starting to feel like a liability. Between the random downtime and the looming shadow of the US Patriot Act, serious European development teams are realizing that where your code lives matters just as much as the quality of the code itself. If you are a CTO or Lead Sysadmin in Norway, sending your intellectual property across the Atlantic adds unnecessary latency and legal ambiguity.
I've seen too many projects stall because a `git push` hung on a transatlantic packet loss, or because a third-party service decided to change their TOS overnight. The solution isn't rocket science—it's bare metal (or a solid VPS) and standard Linux tools. Today, we are going to build a fortress for your code using Ubuntu 12.04 LTS and Gitolite. This setup gives you granular access control, sub-20ms latency if you're in the Nordics, and complete independence.
The Hardware: Why Spindles Are Dead for Git
Before we touch the terminal, let's talk about IOPS. Git is a metadata monster. It generates thousands of tiny objects. If you try to run a busy Git server on standard SATA HDDs, your wait times will skyrocket during large merges or CI checkouts. You need random I/O performance.
This is where CoolVDS becomes the reference architecture. We utilize pure SSD arrays (Solid State Drives) rather than caching layers. In 2012, SSD hosting is still considered a luxury by some, but for version control systems, it's a necessity. The difference between compiling a project cloned from an SSD VPS versus a mechanical drive VPS is the difference between a coffee break and a context switch that ruins your flow.
Step 1: The Base Environment
We assume you have a fresh instance of Ubuntu 12.04 Precise Pangolin. First, secure the perimeter. We aren't using passwords here—SSH keys only.
# Update your repositories
sudo apt-get update && sudo apt-get upgrade -y
# Install Git and essential tools
sudo apt-get install git-core openssh-server build-essential -y
# Create a dedicated git user
sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git
Step 2: Installing Gitolite
While some folks are experimenting with the new GitLab project, it's still heavy on resources (Ruby can be thirsty). For pure, unadulterated speed and management, Gitolite remains the battle-hardened standard for access control without the GUI bloat. It allows you to manage repo permissions via a... git repo. Recursive, elegant, and scriptable.
Log into your local workstation (not the server) and generate an admin key if you haven't already:
# On your LOCAL machine
ssh-keygen -t rsa -b 2048 -f ~/.ssh/git_admin
Now, upload your public key to your CoolVDS instance:
scp ~/.ssh/git_admin.pub root@:/tmp/git_admin.pub
Back on the server, switch to the git user and install Gitolite:
# Login as root, then switch to git user
su - git
# Clone the Gitolite source
git clone git://github.com/sitaramc/gitolite
# Install the binaries
mkdir -p $HOME/bin
./gitolite/install -to $HOME/bin
# Setup the admin key
$HOME/bin/gitolite setup -pk /tmp/git_admin.pub
Pro Tip: Always verify your `/etc/ssh/sshd_config`. Ensure `PasswordAuthentication` is set to `no` and `AllowUsers` includes your maintenance user and the `git` user. A brute-force attack on port 22 can eat up CPU cycles even if they never get in.
Step 3: Managing Repositories
The beauty of this setup is that you never SSH into the server to create repos again. You do it from your workstation. Add the following to your local `~/.ssh/config` to simplify access:
Host my-git-server
HostName
User git
IdentityFile ~/.ssh/git_admin
Now, clone the admin repository:
git clone my-git-server:gitolite-admin
cd gitolite-admin
Inside, you'll find two folders: `conf/` and `keydir/`. To add a new developer, drop their public key into `keydir/`. To create a new repo, edit `conf/gitolite.conf`:
repo cool-project
RW+ = admin
RW = johndoe
R = deploy-bot
Commit and push these changes. Gitolite hooks will instantly configure the server, create the `cool-project` bare repository, and apply the ACLs. It’s instantaneous.
Step 4: The Network Layer & Data Integrity
Running a git server in Norway requires adherence to strict data practices. While we don't have a singular "GDPR" yet, the Norwegian Data Protection Authority (Datatilsynet) is clear about securing personal data. Even commit logs contain names and emails.
Configure `iptables` to only allow traffic on port 22 (SSH) and perhaps 80/443 if you run a web view like cgit later. Drop everything else.
# Simple iptables rules for a dedicated Git server
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP
Performance: The CoolVDS Advantage
When your team grows to 10 or 20 developers, the disk I/O becomes the bottleneck. A `git grep` across a 2GB repository searches through thousands of loose objects. On a shared hosting environment with "noisy neighbors" and mechanical drives, this can take 30 seconds. On CoolVDS SSD instances, it takes 2 seconds.
Why? Because SSDs handle parallel read requests without the seek latency of a physical read head. We specifically tune our KVM virtualization stack to pass through disk performance with minimal overhead. For teams in Oslo or Bergen, combining this I/O speed with the low latency of our local peering ensures your `git push` feels like it's happening on your localhost.
Final Thoughts
Self-hosting isn't just about paranoia; it's about performance and sovereignty. You aren't subject to a US company's terms of service, and you aren't routing traffic through Frankfurt just to commit code to a server in the same city. Build it on solid SSD infrastructure, lock it down with RSA keys, and get back to coding.
Ready to migrate? Spin up a high-performance SSD VPS on CoolVDS today and experience the difference raw I/O speed makes for your development workflow.