Self-Hosted Git Server: A Complete Guide

Services like GitHub and GitLab are fantastic, and already satisfies the need of most as git hosting service. And let me be clear from the start, setting up a self-hosted git server is not for beginners. However, if you have the right need to do so, it can give you TOTAL control over your code, your deployment process, and your infrastructure.

I had the opportunity to work on setting up an custom git based source control server in the past, that would let me push code and deploy it automatically. No complicated CI/CD pipelines, no third-party services, just Git doing what Git does best – managing code.

In this guide, I’ll walk you through the entire process of setting up a self-hosted Git server with automated deployment using Git hooks. Trust me, this will revolutionize your workflow, especially if your use case demands it!

What You’ll Learn

• Setting up a rock-solid Git server on your own VPS
• Configuring Git repositories for both development and production environments
• Creating automated deployment workflows using Git hooks
• Solving common permission issues that trip up most developers
• Advanced techniques for managing multiple environments

Let’s dive in!

Prerequisites

Before we start, make sure you have:

• A VPS running Ubuntu (We will be using Ubuntu 20.04 in this guide, but this should work on other versions too)
• Basic knowledge of Linux commands
• SSH access to your server
• Basic understanding of Git

Part 1: Setting Up Your Self-Hosted Git Server

Installing Git on Your Server

First things first, let’s get Git installed on your server. SSH into your VPS and run:

sudo apt update
sudo apt install git

Nothing fancy here, just the standard Git installation. Once it’s installed, let’s verify:

git --version

You should see something like git version 2.25.1 or newer.

Creating a Git User

For security and organization, we’ll create a dedicated Git user:

sudo adduser git

Follow the prompts to create the user. This user will own all our Git repositories and handle all Git-related operations.

Setting Up SSH Keys for Authentication

Rather than using passwords, we’ll use SSH keys for authentication – it’s more secure and makes automation much easier.

1. On your local machine, generate an SSH key pair if you don’t already have one:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"Code language: JavaScript (javascript)

2. Copy your public key to the server:

ssh-copy-id git@your_server_ipCode language: CSS (css)

3. Test the connection:

ssh git@your_server_ipCode language: CSS (css)

If everything’s set up correctly, you should be able to log in without a password.

Installing Gitolite for Repository Management

While it’s technically optional, I STRONGLY recommend installing Gitolite. It makes managing Git repositories and user access so much easier.

1. Switch to the git user:

sudo su - git

2. Clone the Gitolite repository:

git clone https://github.com/sitaramc/gitoliteCode language: PHP (php)

3. Install Gitolite:

mkdir -p $HOME/bin
gitolite/install -to $HOME/binCode language: PHP (php)

4. Create a public key for the gitolite admin:

mkdir -p $HOME/.ssh
touch $HOME/.ssh/authorized_keysCode language: PHP (php)

5. From your local machine, copy your public key to the server (if you haven’t already):

scp ~/.ssh/id_rsa.pub git@your_server_ip:~/admin.pubCode language: JavaScript (javascript)

6. Set up Gitolite with the admin key:

$HOME/bin/gitolite setup -pk admin.pubCode language: PHP (php)

Now, Gitolite is installed and configured with your key as the admin key.

Cloning the Gitolite Admin Repository

On your local machine, clone the gitolite-admin repository:

git clone git@your_server_ip:gitolite-adminCode language: PHP (php)

This repository is where you’ll manage repositories and users.

Part 2: Managing Repositories and Users

Creating a New Repository

To create a new repository, you’ll need to modify the gitolite configuration:

1. Edit the gitolite-admin/conf/gitolite.conf file:

repo gitolite-admin
    RW+     =   admin

repo testing
    RW+     =   @all

# Add your new repository
repo myproject
    RW+     =   admin
    RW      =   developerCode language: PHP (php)

2. Commit and push the changes:

cd gitolite-admin
git add conf/gitolite.conf
git commit -m "Added myproject repository"
git pushCode language: JavaScript (javascript)

Gitolite will automatically create the repository on the server.

Adding Users

To add a new user:

1. Get their public SSH key and save it to gitolite-admin/keydir/username.pub
2. Update the gitolite.conf file to give them access to repositories
3. Commit and push the changes

For example:

# Add a new developer
repo myproject
    RW+     =   admin
    RW      =   developer @developersCode language: PHP (php)

And in gitolite-admin/keydir, add the new user’s public key as newuser.pub.

Part 3: Setting Up Multi-Environment Deployment with Git Hooks

This is where the magic happens. We’ll set up a single Git repository that deploys to both development and production environments based on the branch being pushed.

Creating the Deployment Directory Structure

1. Create directories for your application:

sudo mkdir -p /var/www/dev/myproject
sudo mkdir -p /var/www/prod/myprojectCode language: JavaScript (javascript)

2. Set the proper ownership:

sudo chown git:www-data /var/www/dev/myproject
sudo chown git:www-data /var/www/prod/myprojectCode language: JavaScript (javascript)

3. Set the proper permissions:

sudo chmod 775 /var/www/dev/myproject
sudo chmod 775 /var/www/prod/myprojectCode language: JavaScript (javascript)

Creating the Post-Receive Hook

The post-receive hook is the secret sauce that makes automated deployment possible. When you push to your repository, this hook will automatically deploy your code to the right environment.

1. Find the hooks directory in your repository:

cd /home/git/repositories/myproject.git/hooks

2. Create a new file called post-receive:

sudo nano post-receive

3. Add the following content:

#!/bin/bash
while read oldrev newrev ref
do
    branch=$(echo $ref | cut -d/ -f3)
    
    if [ "$branch" == "dev" ]; then
        echo "Deploying to development environment..."
        WORK_PATH="/var/www/dev/myproject"
    elif [ "$branch" == "master" ]; then
        echo "Deploying to production environment..."
        WORK_PATH="/var/www/prod/myproject"
    else
        echo "Not deploying branch $branch"
        exit 0
    fi
    
    <em># Check if work path exists</em>
    if [ ! -d "$WORK_PATH" ]; then
        echo "Creating $WORK_PATH..."
        mkdir -p $WORK_PATH
        cd $WORK_PATH
        git clone /home/git/repositories/myproject.git .
        git checkout $branch
    else
        cd $WORK_PATH
        unset GIT_DIR
        git reset --hard
        git checkout $branch
        git pull origin $branch
    fi
    
    <em># Run any additional deployment tasks</em>
    echo "Running deployment tasks..."
    <em># Example: composer install, npm install, etc.</em>
    <em># composer install --no-dev</em>
    <em># npm install --production</em>
    
    <em># Fix permissions</em>
    find $WORK_PATH -type f -exec chmod 664 {} \;
    find $WORK_PATH -type d -exec chmod 775 {} \;
    
    echo "Deployment of $branch completed!"
doneCode language: PHP (php)

4. Make the hook executable:

sudo chmod +x post-receive

This hook will:

• Identify which branch was pushed
• Deploy to the correct environment based on the branch
• Reset any local changes to ensure a clean deployment
• Run any additional deployment tasks
• Fix permissions to ensure your web server can read the files

Part 4: Solving Common Permission Issues

One of the trickiest parts of setting up automated deployment is dealing with permissions. Here are some approaches to solve common issues:

Method 1: Add Web Server User to Git Group

This is a clean approach that works well in most scenarios:

sudo usermod -aG git www-data

Then, make sure group permissions are properly set:

sudo chmod g+s /var/www/dev/myproject
sudo chmod g+s /var/www/prod/myprojectCode language: JavaScript (javascript)

This ensures new files inherit the group permissions.

Method 2: Run Web Server as Git User

If you have control over your web server configuration, you can run it as the git user:

For Nginx:

sudo nano /etc/nginx/nginx.conf

Change the user at the top:

user git;

For Apache:

sudo nano /etc/apache2/envvars

Change the following lines:

export APACHE_RUN_USER=git
export APACHE_RUN_GROUP=gitCode language: JavaScript (javascript)

Restart your web server after making these changes.

Method 3: Use ACLs for Fine-Grained Permissions

If you need more complex permission management:

sudo apt install acl
sudo setfacl -R -m u:git:rwX,u:www-data:rwX /var/www/dev/myproject
sudo setfacl -R -d -m u:git:rwX,u:www-data:rwX /var/www/dev/myprojectCode language: JavaScript (javascript)

This gives both users full access to the directory.

Part 5: Advanced Configuration and Optimization

Setting Up Branch-Specific Deployment Rules

You can extend the post-receive hook to handle more complex scenarios, like deploying specific branches to specific subdomains:

if [ "$branch" == "feature-x" ]; then
    echo "Deploying feature-x to its dedicated environment..."
    WORK_PATH="/var/www/features/feature-x"
fiCode language: PHP (php)

Implementing Deployment Notifications

Add notification functionality to your post-receive hook:

# Send deployment notification
notify() {
    local branch=$1
    local env=$2
    local message="Deployment of $branch to $env completed!"
    
    <em># Send email notification</em>
    echo "$message" | mail -s "Deployment Notification" your-email@example.com
    
    <em># Or send Slack notification</em>
    curl -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"$message\"}" \
    https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK
}

# Call the function after deployment
notify $branch "production"Code language: PHP (php)

Setting Up Rollback Mechanism

Add a simple rollback capability:

# Create a rollback function
rollback() {
    local branch=$1
    local work_path=$2
    
    cd $work_path
    git reset --hard HEAD~1
    
    echo "Rolled back $branch to previous commit"
}

# You can call this function manually or add logic to trigger it automaticallyCode language: PHP (php)

Part 6: Securing Your Self-Hosted Git Server

Security is crucial when hosting your own Git server. Here are some essential steps:

Restricting SSH Access

Edit the SSH config to restrict git user access to Git commands only:

sudo nano /etc/ssh/sshd_config

Add the following lines:

Match User git
    ForceCommand /usr/bin/gitolite-shell
    PasswordAuthentication no
    AllowTcpForwarding no
    X11Forwarding no

Restart SSH:

sudo systemctl restart sshd

Setting Up Firewall Rules

Install and configure UFW (Uncomplicated Firewall):

sudo apt install ufw
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

Enabling HTTPS for Git Operations

For secure Git operations, set up HTTPS:

1. Install Apache or Nginx
2. Install Let’s Encrypt certificates
3. Configure your web server to use HTTPS
4. Update your Git remote URLs to use HTTPS

Part 7: Best Practices for Self-Hosted Git Servers

Regular Backups

Set up regular backups of your Git repositories:

# Create a backup script
sudo nano /usr/local/bin/backup-git.shCode language: PHP (php)

Add the following content:

#!/bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/var/backups/git/$DATE"

mkdir -p $BACKUP_DIR

# Backup repositories
tar -czf $BACKUP_DIR/git-repos.tar.gz /home/git/repositories

# Keep backups for 30 days
find /var/backups/git -type d -mtime +30 -exec rm -rf {} \;Code language: PHP (php)

Make it executable and add a cron job:

sudo chmod +x /usr/local/bin/backup-git.sh
sudo crontab -e

Add the following line:

0 2 * * * /usr/local/bin/backup-git.shCode language: JavaScript (javascript)

Monitoring Your Git Server

Install basic monitoring tools:

sudo apt install htop iotop

For more comprehensive monitoring, consider setting up Prometheus and Grafana.

Maintaining Your Git Server

Regular maintenance is essential:

# Update system packages
sudo apt update && sudo apt upgrade -y

# Clean up old Git objects
cd /home/git/repositories/myproject.git
git gc --aggressiveCode language: PHP (php)

Conclusion: The Power of Self-Hosted Git with Automated Deployment

Setting up a self-hosted Git server with automated deployment might seem like a lot of work at first, but the benefits are ENORMOUS. You get:

1. Complete control over your code and infrastructure
2. Automated deployment without depending on third-party services
3. Custom workflows tailored to your specific needs
4. Enhanced security with SSH key authentication
5. Significant cost savings over paid Git hosting services

The ability to push code and have it automatically deployed to the right environment without any manual intervention is incredibly powerful. Taking control of your Git infrastructure gives you flexibility and power that’s hard to match with third-party services.

So, what use case you are trying to solve for with your own self-hosted Git server? Let me know in the comments.

Frequently Asked Questions

Can I use this setup with Windows servers?

While this guide focuses on Linux-based servers, you can adapt the concepts to Windows servers using Git for Windows and PowerShell scripts instead of bash.

Is self-hosting Git secure?

Yes, with proper configuration. The key is to use SSH keys for authentication, restrict access appropriately, and keep your server updated.

How do I handle database migrations during deployment?

You can add database migration commands to your post-receive hook, but be careful with production databases. Consider using a migration framework that supports versioning and rollbacks.

Can I use this approach with containers or Kubernetes?

Absolutely! The post-receive hook can trigger container builds and deployments. You’d modify the hook to build and deploy containers instead of directly updating files.

How do I scale this setup for larger teams?

For larger teams, consider adding more structure to your gitolite configuration, implementing code review processes, and potentially using additional tools like Gerrit or GitLab for merge request management.

Additional Resources:

• Setting Up Git Server
• Creating SSH Key pair