Stop Using FTP: Architecting a Secure Git Server with Gitolite for High-Velocity Teams
If you are still dragging and dropping files via FTP in 2012, you are not deploying software; you are playing Russian Roulette with your codebase. I’ve seen entire production environments implode because a developer overwrote config.php with a three-month-old version from their laptop. It’s messy, it’s unprofessional, and quite frankly, it’s negligent.
The industry is moving to Git. Distributed version control isn't just a trend; it's the new baseline for sanity. While GitHub is excellent for open source, trusting your proprietary intellectual property to a third-party cloud in the US can be a headache, especially with the Datatilsynet (Norwegian Data Inspectorate) tightening the screws on data export under the Personal Data Act (Personopplysningsloven).
In this guide, we are going to build a fortress. We will deploy a private, self-hosted Git server using Gitolite on a CoolVDS CentOS 6 instance. This setup gives you granular access control, zero licensing fees, and the raw speed of local hosting.
The Hardware: Why Latency Kills Workflow
Before we touch the terminal, let’s talk iron. Git is fast, but it’s I/O heavy during operations like git gc (garbage collection) or cloning massive repositories. If you run this on a cheap, oversold VPS with spinning rust (standard HDDs) and high steal time, your developers will spend half their day waiting for SSH handshakes.
I recently migrated a Magento development team from a budget German host to a CoolVDS instance located here in Oslo. Their git push times dropped from 4 seconds to 400 milliseconds. When you multiply that by 50 commits a day across 10 developers, you are saving hours of productivity every week. We use KVM virtualization to ensure that the RAM and CPU you pay for are actually yours—no noisy neighbors stealing your cycles.
Step 1: The Foundation
We will assume you are using CentOS 6.2. First, we need to secure the perimeter. We never use root for application logic. We need a dedicated git user.
# Update the system first
yum update -y
# Install core dependencies
yum install -y git perl openssh-clients openssh-server
# Create the git user
adduser git
passwd -l git # Disable password login, keys only!
This locks down the account. If you don't have an SSH key pair on your local machine yet, generate one now. Do not share keys. Every developer gets their own.
# On your LOCAL machine
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa_git_admin
Step 2: Installing Gitolite
Gitolite is a Perl layer that sits on top of Git. It uses a single system user (git) but differentiates between developers based on their SSH keys. It’s the engine that powers many enterprise forges.
Log into your VPS and switch to the git user. We will clone the Gitolite source directly. I prefer installing from source over RPMs to ensure we have the latest v3 features.
# Login to your VPS
ssh root@your-coolvds-ip
# Copy your local public key to the server first
# (Do this from your local machine via scp)
# scp ~/.ssh/id_rsa_git_admin.pub root@your-coolvds-ip:/tmp/admin.pub
# Switch to git user
su - git
# Setup bin directory
mkdir -p ~/bin
# Clone Gitolite
git clone git://github.com/sitaramc/gitolite
# Install
./gitolite/install -to ~/bin
# Setup the admin key
~/bin/gitolite setup -pk /tmp/admin.pub
If you see an empty output or minimal confirmation, that’s good UNIX design. Silence means success.
Pro Tip: Always use a high-performance filesystem. CoolVDS instances come formatted with ext4 on Enterprise SSD storage arrays (RAID 10). Git involves thousands of tiny file operations. On standard SATA drives, the IOPS bottleneck will choke your CI/CD pipeline. On our SSDs, it flies.
Step 3: Configuring Access Control
Here is the magic of Gitolite: You don't administer the server by SSH-ing into it anymore. You administer it by pushing to a special git repository called gitolite-admin.
Back on your local machine, clone the admin repo:
# Add config to ~/.ssh/config to simplify access
Host git-server
HostName your-coolvds-ip
User git
IdentityFile ~/.ssh/id_rsa_git_admin
# Clone the admin repo
git clone git-server:gitolite-admin
Inside, you will find two directories: conf/ and keydir/. To add a new developer (let's call him "Lars"), you simply drop lars.pub into keydir/ and edit conf/gitolite.conf.
Here is an example configuration for a typical agency setup:
repo gitolite-admin
RW+ = admin
repo testing
RW+ = @all
# A real project
repo nord-commerce
RW+ = admin
RW = lars silje
R = jenkins-ci
Commit and push these changes. Gitolite’s hooks will immediately update the ~/.ssh/authorized_keys file on the server. It’s seamless.
Step 4: Automating Deployment with Hooks
A repository is useless if code just sits there. You need it to go live. In 2012, complex CI servers like Jenkins can be overkill for smaller projects. A simple post-receive hook is often the most robust solution.
On the server (as the git user), go to the bare repository:
cd /home/git/repositories/nord-commerce.git/hooks
vi post-receive
Add this script to deploy to your web root automatically:
#!/bin/sh
GIT_WORK_TREE=/var/www/html/nord-commerce git checkout -f master
# Restart Nginx or PHP-FPM if needed
# sudo /etc/init.d/nginx reload
Make it executable:
chmod +x post-receive
Security & Network Considerations
Security isn't an addon; it's the architecture. Running your own Git server means you are responsible for it.
- Change the SSH Port: Bots scan port 22 constantly. Move your SSH daemon to port 2222 or similar in
/etc/ssh/sshd_configto reduce log noise. - Disable Password Auth: Ensure
PasswordAuthentication nois set. Keys are the only way in. - DDoS Protection: Even a private development server can be a target. CoolVDS provides network-level ddos protection that filters traffic before it hits your NIC, ensuring your team can keep pushing code even if the network is under stress.
Why Hosting in Norway Matters
Latency is physics. The speed of light is finite. If your team is in Oslo or Bergen, hosting your Git repo in Virginia (US) adds 100ms+ to every packet. For an interactive SSH session, that lag is torture. By using VPS Norway infrastructure, you keep ping times under 10ms.
Furthermore, keeping your data within Norwegian borders satisfies the requirements of the Personal Data Act. You don't have to worry about the complexities of Safe Harbor frameworks if the data never leaves the country.
Conclusion
Centralized version control is a relic. By setting up Gitolite on a dedicated server, you gain control, speed, and security. You aren't dependent on a SaaS provider's uptime, and you aren't leaking metadata to third parties.
The setup requires a bit of Linux knowledge, but the payoff is absolute ownership of your workflow. Don't let slow I/O kill your momentum. If you need a rock-solid foundation for your code, deploy a test instance on CoolVDS today. Our managed hosting support team can even help you configure the initial SSH handshake if you get stuck.
Next Step: Provision a CentOS 6 SSD VPS in our Oslo datacenter and run the install script above. Your team will thank you.