Secure, Private Git Hosting: Building a Fortress in Norway
If you are still using Subversion (SVN) in 2011, you are fighting a losing battle. The centralized model is slow, it breaks when your network drops, and merging branches is a nightmare that ruins weekends. Linus Torvalds gave us Git for a reason.
But here is the problem: putting your proprietary code on public clouds or US-based servers is a risk many Norwegian CTOs are finally waking up to. Latency kills productivity, and the legal gray areas around data handling are widening. You need your code close to your developers, and you need it under your absolute control.
This isn't just about software; it's about infrastructure. I have seen distributed teams grind to a halt because their "cloud" Git host was routing traffic through a congested node in Frankfurt while the team was sitting in Oslo. Physics always wins.
Why Self-Host Git?
Services like GitHub are great for open source, but for enterprise collaboration, you want:
- Speed: A
git cloneover a local connection at NIX (Norwegian Internet Exchange) speeds is instant. Crossing the Atlantic is not. - Privacy: With the Data Retention debates heating up in Europe, keeping your intellectual property on a server governed by Norwegian law is just common sense.
- Cost Control: You shouldn't pay per user. You should pay for the metal.
The Architecture: Raw Power over Convenience
We aren't setting up a heavy GUI here. We are setting up a raw, efficient SSH-based Git server. For this setup, I recommend a CoolVDS Virtual Dedicated Server running CentOS 5.6 or Debian 6 (Squeeze).
Pro Tip: Git operations, specifically git gc (garbage collection) and repacking, are I/O intensive. Most cheap VPS providers oversell their storage, putting you on crowded spinning disks. At CoolVDS, we utilize enterprise-grade RAID-10 storage arrays. Do not bottle-neck your development workflow to save 50 kroner a month.
Step-by-Step Implementation
1. Prepare the Environment
Log into your CoolVDS instance via SSH. First, ensure your packages are up to date. Security patches are not optional.
yum update -y
yum install git -y
If you are on Debian/Ubuntu, use apt-get install git-core. Note that in some older distributions, the package is just git-core.
2. Create the Git User
We never run services as root if we can help it. Isolate the damage.
adduser git
passwd git
3. Setting Up SSH Access
The beauty of Git is that it leverages existing SSH security. You don't need a complex daemon listening on a new port. Gather the public keys (id_rsa.pub) from your developers.
On the server, switch to the git user and set up the authorized keys:
su - git
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
Paste your developers' public keys into that authorized_keys file, one per line.
4. The Bare Repository
This is where many newcomers get confused. A server repository should be "bare"—meaning it has no working directory (no actual files visible), just the version control database. This prevents data corruption if someone tries to push to a non-bare repo.
cd /home/git
mkdir project.git
cd project.git
git init --bare
5. Client-Side Configuration
Now, back on your local machine (your laptop in Oslo, Bergen, or Trondheim), you add this remote using the low-latency IP of your CoolVDS server.
git remote add origin git@your-coolvds-ip:project.git
git push origin master
Managing Access: The "Gitolite" Solution
The method above grants full access to everyone with a key. For larger teams needing granular control (Read vs. Write permissions per branch), you should look into Gitolite. It sits on top of SSH and uses a perl script to mediate access. It is currently the industry standard for self-hosted access control.
Network Performance and Hardware
When your repository grows to 2GB+, network throughput matters. Standard shared hosting often caps bandwidth or throttles connections during peak hours.
This is why we engineer CoolVDS for consistency. We use KVM virtualization (kernel-based virtual machine), which provides true hardware isolation compared to container-based solutions like OpenVZ. When you are compiling code or repacking large Git objects, you need guaranteed CPU cycles, not "burstable" resources that vanish when the neighbor gets busy.
Latency Check
Before you deploy, run a ping test to your current host vs. CoolVDS. If you are developing in Norway, you want single-digit latency.
| Source | Target: US East Coast | Target: CoolVDS (Oslo) |
|---|---|---|
| Oslo Fiber | ~90-110ms | ~2-5ms |
That 100ms difference adds up every time you run git status against a remote or fetch changes.
Conclusion
Stop tolerating slow pushes and questionable data sovereignty. Setting up a private Git server takes 15 minutes and gives you complete ownership of your workflow.
Don't let slow disk I/O kill your team's momentum. Deploy a high-performance instance on CoolVDS today and feel the difference of local, dedicated resources.