The Illusion of Cloud Security: Why Your Code Belongs on Your Own Metal

It is 2012, and the trend of offloading critical infrastructure to "the cloud" is reaching a fever pitch. We see startups blindly pushing proprietary algorithms to GitHub or Bitbucket, trusting US-based entities with their intellectual property. While convenient, this ignores two fundamental realities for Nordic developers: the legal ambiguity of the US Patriot Act and the physics of latency.

If your team is in Oslo or Bergen, why are you pushing commits to a server in San Francisco? The round-trip time (RTT) kills your productivity during large pulls, and frankly, you don't own that metal.

As a systems architect who has watched redundant arrays crumble, I advocate for total control. Today, we are building a centralized, secure Git server using Gitolite on CentOS 6.3. We will use a CoolVDS KVM instance because we need strict kernel-level control and guaranteed I/O—things you simply do not get with oversold OpenVZ containers.

The Architecture: Why Gitolite?

You might be tempted to just create Unix users for everyone. Don't. That is a security nightmare. Gitolite allows you to use a single Unix user on the server while distinguishing between multiple remote developers via SSH keys. It provides granular access control (branch-level permissions) without giving your junior dev shell access to the production server.

Prerequisites

• A CoolVDS KVM Slice (Recommended: 1GB RAM minimum for decent pack-file performance).
• CentOS 6.3 (64-bit).
• Root access.
• Your local workstation's public SSH key (id_rsa.pub).

Pro Tip: When choosing your VPS, pay attention to the underlying storage. Git is heavy on random I/O operations, especially when garbage collecting or repacking large repositories. CoolVDS offers SSD-cached storage tiers which significantly outperform standard SATA builds found elsewhere. If `git status` feels slow, it's usually your disk, not your CPU.

Step 1: The Initial Harden

Before installing applications, we secure the perimeter. We are operating under Norwegian jurisdiction, but the internet is global. We need a basic firewall.

First, update your system and install the EPEL repository, as standard CentOS repos are often behind on Git versions.

[root@coolvds ~]# yum update -y
[root@coolvds ~]# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@coolvds ~]# yum install git perl-Time-HiRes -y

Now, configure iptables. We only want SSH (port 22) open for now.

[root@coolvds ~]# iptables -I INPUT -p tcp --dport 22 -j ACCEPT
[root@coolvds ~]# iptables -A INPUT -j REJECT
[root@coolvds ~]# service iptables save

Step 2: Creating the Git User

We create a dedicated system user. This user will hold all repositories and keys. Do not use root.

[root@coolvds ~]# adduser git
[root@coolvds ~]# passwd -l git

Locking the password with -l ensures this user can only be accessed via SSH keys, preventing brute-force password attacks.

Step 3: Installing Gitolite

Log in as the git user. This is where the magic happens. We will clone the Gitolite source directly to ensure we have the latest stable v3 release.

[root@coolvds ~]# su - git
[git@coolvds ~]$ mkdir -p $HOME/bin
[git@coolvds ~]$ git clone git://github.com/sitaramc/gitolite
[git@coolvds ~]$ ./gitolite/install -to $HOME/bin

Now, we need to initialize Gitolite with your workstation's public key. Upload your local id_rsa.pub to the server (use SCP from your local machine) and save it as /tmp/admin.pub.

[git@coolvds ~]$ $HOME/bin/gitolite setup -pk /tmp/admin.pub

Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/
WARNING: /home/git/.ssh/authorized_keys missing; creating a new one

If you see the output above, you have successfully deployed the fortress.

Step 4: Managing Access (The "cool" part)

Here is where the workflow shifts. You do not manage users by logging into the server anymore. You manage the server using Git.

On your local workstation:

[local@workstation ~]$ git clone git@your-coolvds-ip:gitolite-admin
Cloning into 'gitolite-admin'...
remote: Counting objects: 6, done.
Receiving objects: 100% (6/6), done.

Inside this folder, you will find two directories: conf/ and keydir/.

• keydir/: Drop your developers' public keys here (e.g., jens.pub, ola.pub).
• conf/gitolite.conf: Define your repos and permissions.

Edit the config file to add a new project for your team:

repo    nordic-project
        RW+     =   admin
        RW      =   jens ola
        R       =   intern-lars

Commit and push this change. Gitolite hooks will automatically create the repository on the CoolVDS server and update the ~/.ssh/authorized_keys file. This is automation at its finest.

Performance Tuning for High Load

If your team grows or your repositories involve heavy binary assets, default Git configurations can choke. On a VPS environment, memory management is critical.

We recommend adjusting Git's garbage collection usage in your global config on the server:

[git@coolvds ~]$ git config --global pack.windowMemory "256m"
[git@coolvds ~]$ git config --global pack.packSizeLimit "256m"
[git@coolvds ~]$ git config --global core.packedGitWindowSize "256m"

These settings prevent Git from attempting to map massive pack files entirely into RAM, which can trigger the OOM (Out of Memory) killer on smaller VPS instances. This is a common issue we see with Magento or typo3 repositories.

Why Infrastructure Matters

You can run this setup on a generic budget host, but you will feel the pain during the handshake. SSH negotiation and Git pack compression are CPU intensive.

At CoolVDS, we utilize enterprise-grade hardware with KVM virtualization. Unlike OpenVZ, KVM provides full isolation. If a neighbor abuses their CPU, your Git encryption speeds remain stable. Furthermore, hosting in our Oslo datacenter ensures that your data falls under Norwegian privacy laws (Personopplysningsloven) and stays compliant with EU Directive 95/46/EC, keeping your proprietary code away from prying foreign eyes.

Final Verification

To ensure everything is working, verify your SSH access:

ssh git@your-coolvds-ip info

You should see a greeting listing your available repositories. If you do, congratulations. You have just declared independence from the cloud giants.

Ready to own your infrastructure? Deploy a KVM instance on CoolVDS today and experience the stability of true Nordic hosting.