Stop Outsourcing Your IP: Deploying a Secure Git Server on Ubuntu 12.04 LTS
Let’s be honest for a second. "The Cloud" is just a marketing term for "someone else's computer." When you push your proprietary code to GitHub or Bitbucket, you are trusting a third party with your company's crown jewels. You are also routing your push/pull requests through data centers that might be halfway across the globe. If you are sitting in Oslo, why should your code travel to San Francisco and back just to reach your colleague in Bergen?
I’ve seen development teams grind to a halt because a transatlantic fiber cut added 200ms of latency to every git operation. When you are dealing with a 2GB repo and tight deadlines, that latency isn't just annoying; it's a financial liability.
In this guide, we are cutting out the middleman. We are setting up a private, secure, and blazing fast Git server on a CoolVDS instance running Ubuntu 12.04 LTS (Precise Pangolin). No web interfaces, no bloat, just pure SSH transport and raw speed.
The Architecture: SSH and Bare Repos
We don't need heavy management layers. Git was designed by Linus Torvalds to work seamlessly over SSH. By using standard Linux permissions and SSH keys, we can create a system that is more secure than most SaaS offerings because the attack surface is exactly as small as you make it.
Step 1: The Foundation
First, secure your VPS. I assume you are using a fresh install of Ubuntu 12.04. Update your repositories immediately to patch any known vulnerabilities.
sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install git-core openssh-server
Step 2: Create the Git User
We never run services as root. We create a dedicated 'git' user to handle the repositories. This isolates the code from the rest of the system.
sudo adduser git
su - git
Step 3: SSH Key Management
Password authentication is for amateurs. It’s susceptible to brute-force attacks and cumbersome for automation. We will enforce SSH key authentication. On your local machine (the developer's laptop), generate a key pair if you haven't already:
# On your local machine, not the server
ssh-keygen -t rsa -b 2048 -C "dev@company.no"
Now, copy the public key (`id_rsa.pub`) to your CoolVDS server. Inside the `git` user's home directory on the server:
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
cat /tmp/id_rsa.pub >> .ssh/authorized_keys
Pro Tip: If you have a large team, manually managing `authorized_keys` gets tedious. In that case, look into Gitolite (v3 is stable now). It uses a git repo to manage the access rules for your other git repos. But for teams under 10, manual keys are simpler and less prone to configuration breakage.
The Storage Layer: Why I/O Matters
This is where most VPS providers fail. Git is essentially a specialized filesystem. It creates thousands of small objects, compresses them (zlib), and moves them around. When you run `git gc` (garbage collection) or clone a massive repo, you are hammering the disk with random I/O operations.
I once debugged a "slow git" issue for a client hosting on a budget provider with traditional spinning hard drives (HDD). Their `git status` command on a large Magento project took 12 seconds because the disk seek time was abysmal. Moving them to CoolVDS reduced that to 0.4 seconds.
Why? Because CoolVDS uses enterprise-grade SSD storage. In 2012, SSDs are still a premium feature for many hosts, but for development infrastructure, they are non-negotiable. If your VPS suffers from "I/O wait," your developers are getting paid to stare at a blinking cursor.
Creating the Repository
Back on the server, as the `git` user, create a "bare" repository. A bare repo contains the version history but no working tree (no actual files you can edit directly). This is standard for a central push destination.
cd /home/git
mkdir project.git
cd project.git
git init --bare
# Output: Initialized empty Git repository in /home/git/project.git/
Connecting from Local
On your developer machine, add the remote and push. Replace `192.0.2.10` with your CoolVDS IP address.
cd my-local-project
git init
git add .
git commit -m "Initial commit"
git remote add origin git@192.0.2.10:project.git
git push origin master
If you set up the keys correctly, it won't ask for a password. It will just fly.
Local Compliance and Latency
Operating in Norway comes with specific legal and technical realities. Under the Personopplysningsloven (Personal Data Act), you have a responsibility to safeguard data. By hosting on a VPS Norway provider like CoolVDS, you ensure that your data physically resides within Norwegian jurisdiction, simplifying compliance with Datatilsynet auditing.
Furthermore, network topology is physics. If your office is in Oslo and your server is in a CoolVDS datacenter peered directly at NIX (Norwegian Internet Exchange), your latency will likely be under 5ms. Compare that to 150ms+ for US-based hosting. That snappy response time keeps the "flow state" of coding uninterrupted.
Hardening the Setup
To finish, let's lock down the `git` user so they can only use git-shell, and not get a full terminal prompt. This restricts the attack vector significantly.
# Verify where git-shell is located
which git-shell
# /usr/bin/git-shell
# Edit /etc/passwd using vipw
sudo vipw
# Change:
# git:x:1001:1001:,,,:/home/git:/bin/bash
# To:
# git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
Now, if someone tries to SSH in as `git` to run commands, the connection will close immediately. They can only push and pull code.
Conclusion
You don't need a bloated web interface to collaborate effectively. You need reliability, security, and raw I/O performance. By controlling your own Git server, you eliminate monthly user fees and keep your intellectual property strictly within your own infrastructure.
Don't let slow rotational disks kill your team's velocity. Deploy a high-performance SSD VPS instance on CoolVDS today and experience what sub-millisecond latency feels like.