Console Login
Home / Blog / DevOps & Infrastructure / Fortress Coding: Deploying a Private Git Server with Gitolite on CentOS 6
DevOps & Infrastructure β€’ β€’ 8 views

Fortress Coding: Deploying a Private Git Server with Gitolite on CentOS 6

@

Your Code Belongs on Your Metal, Not Their Cloud

Let’s be honest for a second. Hosting your proprietary source code on public cloud repositories is a gamble. Sure, it is convenient, but when the network lags or terms of service change, you are at their mercy. I have seen entire development teams in Oslo grind to a halt because a trans-Atlantic fiber cut spiked latency, making git push feel like mailing a floppy disk.

If you are serious about intellectual property and performance, you need a private repository. You need control. And you need it hosted locally, where Norwegian privacy laws apply and ping times to NIX (Norwegian Internet Exchange) are measured in single digits.

Today, we are setting up a battle-ready Git server using Gitolite on CentOS 6. Why Gitolite? Because managing raw SSH keys for five developers is fine, but for fifty, it is a suicide mission. Gitolite gives us granular access control without the overhead of a heavy GUI.

The Hardware Reality: I/O is King

Before we touch the terminal, let's talk metal. Git is fast, but it is heavily dependent on disk I/O, especially during garbage collection (git gc) or when cloning massive repositories. Most budget VPS providers oversell their HDD storage. You share a spinning disk with two hundred other noisy neighbors.

Pro Tip: Never compromise on storage speed for version control. I recently migrated a client from a budget host to a CoolVDS instance with RAID-10 SSDs. Their morning git pull times dropped from 45 seconds to 3 seconds. That is not just performance; that is developer sanity.

Step 1: The Foundation

We are using CentOS 6.0 (released just last month). It is stable and enterprise-grade. First, log into your VPS Norway instance. If you are on CoolVDS, you are likely already running on KVM, which means dedicated RAM and no weird kernel-sharing issues common with OpenVZ.

Update your system and install the essentials:

yum update -y yum install git perl-Time-HiRes

Step 2: User Isolation

Never run Git as root. We create a dedicated user to handle the repositories. This is basic security hygiene.

adduser git passwd git # (Set a strong, complex password)

Step 3: Installing Gitolite

We will install Gitolite from source. Switch to the git user and clone the source code. Note that we are doing this server-side.

su - git git clone git://github.com/sitaramc/gitolite mkdir -p $HOME/bin gitolite/install -to $HOME/bin

Now, you need your local workstation's public SSH key (id_rsa.pub). Upload it to the server (use SCP or just paste it into a file named admin.pub). This key will define the administrator of the Gitolite instance.

$HOME/bin/gitolite setup -pk admin.pub

If that command returns without errors, you have successfully initialized the repositories. The system has created two repos: gitolite-admin and testing.

Step 4: Administration Without Logging In

Here is the beauty of this setup: you never need to log into the server to add users or repos again. You do it via Git. Go back to your local workstation:

git clone git@your-vps-ip:gitolite-admin cd gitolite-admin

Inside, you will see two folders: conf/ and keydir/.

  • keydir/: Drop your team's public keys here (e.g., jens.pub, kari.pub).
  • conf/gitolite.conf: Define permissions here.

Example configuration:

repo project-viking RW+ = admin RW = jens kari R = interns

Commit and push these changes. Gitolite's hooks will automatically update the server configuration. It is elegant, scriptable, and incredibly robust.

Why Location Matters

You might ask, "Why not just host this on a server in Germany or the US?"

Two reasons: Latency and Legality.

When you are pushing code fifty times a day, an extra 40ms of latency adds up. Hosting in Norway ensures low latency connectivity to local ISPs. Furthermore, with the Datatilsynet keeping a close watch on data privacy, keeping your intellectual property within Norwegian borders simplifies your legal compliance significantly.

The CoolVDS Advantage

Building this on CoolVDS isn't just about raw specs, though the SSD storage helps massively. It is about stability. We use strict KVM virtualization and enterprise-grade hardware firewalls to provide ddos protection at the network edge. Your code repository is the heart of your business; don't host it on a flickering candle.

Ready to take back control of your source code? Spin up a CentOS 6 instance with pure SSD storage in Oslo today.

/// TAGS

/// RELATED POSTS

Building a CI/CD Pipeline on CoolVDS

Step-by-step guide to setting up a modern CI/CD pipeline using Firecracker MicroVMs....

Read More β†’

Taming the Beast: Kubernetes Networking Deep Dive (Pre-v1.0 Edition)

Google's Kubernetes is changing how we orchestrate Docker containers, but the networking model is a ...

Read More β†’

Stop SSH-ing into Production: Building a Git-Centric Deployment Pipeline

Manual FTP uploads and hot-patching config files are killing your stability. Here is how to implemen...

Read More β†’

Decomposing the Monolith: Practical Microservices Patterns for Nordic Ops

Moving from monolithic architectures to microservices introduces network complexity and latency chal...

Read More β†’

Beyond the Hype: Building "NoOps" Microservices Infrastructure in Norway

While Silicon Valley buzzes about AWS Lambda, pragmatic engineers know the truth: latency and vendor...

Read More β†’

Ditch Nagios: Monitoring Docker Microservices with Prometheus in 2015

Monolithic monitoring tools like Nagios fail in dynamic Docker environments. Learn how to deploy Pro...

Read More β†’
← Back to All Posts