Private Git Hosting on a Pi — CommunityConduit

Host your organization's code, policies, and documentation on a self-managed Git server using a Raspberry Pi, eliminating dependency on GitHub and keeping intellectual property under your control.

GitHub has become the default place to store code, but it is not the only option—and for many nonprofits, it is not the best option. Terms of service change. Free tiers accumulate restrictions. Repository access can be revoked without warning. Most critically, your organization's training manuals, fundraising scripts, and custom application code live on someone else's servers, subject to their scanning, their training datasets, and their availability.

A Raspberry Pi running a bare Git server costs less than a year of GitHub Pro and keeps every byte of your intellectual property on hardware you control. The setup is simpler than most people assume, and the skills it teaches—SSH key management, repository permissions, and remote workflow discipline—are exactly the ones volunteers need to graduate from casual contributors to competent administrators.

Why Self-Hosted Git?

Version control is not just for software developers. A nonprofit can use Git to track:

Policy documents: Board resolutions, staff handbooks, and grant applications with full edit history
Website source: Static site generators, HTML, CSS, and deployment scripts
Training curricula: Lesson plans, presentation slides, and facilitator notes
Configuration files: Ansible playbooks, Docker Compose files, and system setup scripts
Data processing scripts: Python or R scripts that clean and analyze program metrics

Every change is timestamped, attributed, and reversible. When a volunteer accidentally deletes the summer program schedule, you roll back in thirty seconds. When a funder asks when a specific policy was enacted, you produce the exact commit.

Self-hosting adds sovereignty. No private repository limits. No API rate caps. No surprise billing when your team grows. And if the internet goes down, your LAN-connected volunteers can still commit, branch, and merge locally.

What You Need

Raspberry Pi 3 or newer with Raspberry Pi OS
A USB drive or external SSD for repository storage (optional but recommended)
SSH access configured on the Pi
Basic familiarity with Git commands on the client side

Setting Up the Git User

Create a dedicated system user for Git operations:

sudo adduser --system --group --shell /bin/bash git
sudo mkdir /srv/git
sudo chown git:git /srv/git

This isolates repository access from your primary user account and provides a clean separation of duties.

Creating a Repository

Switch to the git user and initialize a bare repository (a Git repo with no working directory — used as a shared central server that others push to and pull from):

sudo su - git
cd /srv/git
git init --bare example-repo.git

A bare repository has no working directory. It exists solely to receive pushes and serve clones. That is the correct form for a central server.

Set permissions so group members can write:

chmod -R g+rwX /srv/git/example-repo.git

Exit back to your regular user:

exit

Connecting Clients via SSH

On each client machine, generate an ed25519 SSH key (a modern SSH key type — more secure and faster than the older RSA format) if one does not exist:

ssh-keygen -t ed25519 -C "volunteer@yourorg.org"

Copy the public key to the Pi:

ssh-copy-id -i ~/.ssh/id_ed25519.pub git@YOUR_PI_IP

On the Pi, append the key to the git user's authorized_keys file. If ssh-copy-id is unavailable, do it manually:

cat ~/.ssh/id_ed25519.pub | ssh git@YOUR_PI_IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Cloning and Pushing

On the client, clone the repository:

git clone git@YOUR_PI_IP:/srv/git/example-repo.git
cd example-repo

Make a change, commit, and push:

echo "# Program Handbook" > README.md
git add README.md
git commit -m "init: add handbook placeholder"
git push origin main

The workflow is identical to GitHub, except the remote URL points to your Pi instead of github.com.

Scaling Up: Multiple Repositories and Multiple Users

Create additional repositories by repeating git init --bare in /srv/git/. For team access, add each volunteer's SSH public key to /home/git/.ssh/authorized_keys. They all share the git user, but commits remain individually attributed through Git's user.name and user.email configuration on each client machine.

For more granular access control, install Gitea or Forgejo—lightweight web interfaces that run well on a Pi. They provide per-user accounts, repository permissions, pull requests, and issue tracking without the overhead of GitLab. Both are distributed as single binaries with minimal setup.

Install Gitea quickly:

wget -O gitea https://dl.gitea.com/gitea/1.22/gitea-1.22-linux-arm64
chmod +x gitea
sudo mv gitea /usr/local/bin/

Create a service file at /etc/systemd/system/gitea.service and start it. The web interface will be available on port 3000.

Backup Strategy

Repositories are only as safe as your backups. Because Git is distributed, every clone is a backup—but it is an incomplete one unless you back up all branches. Automate a mirror backup to a second Pi or an external drive:

#!/bin/bash
# /home/git/backup.sh
DATE=$(date +%Y%m%d)
rsync -avz --delete /srv/git/ /mnt/backup/git-${DATE}/

Schedule it nightly:

0 3 * * * /home/git/backup.sh

Store one copy offsite if possible. A weekly rsync to a volunteer's home Pi counts, and it costs nothing.

Training Volunteers in Git Workflow

Git is famously intimidating to newcomers. Lower the barrier with a simplified, paper-based workflow:

Pull: git pull before you start editing.
Edit: Make your changes.
Stage: git add filename for each file you touched.
Commit: git commit -m "brief description of what you changed"
Push: git push

Print this five-step card and laminate it. When a volunteer inevitably deletes something, show them git log, identify the broken commit hash, and run git revert HASH. That single rescue builds more confidence than any tutorial.

Why This Matters for Nonprofits

Intellectual property is not just patentable inventions. It is your grant narratives, your volunteer training sequences, your custom registration forms, and your hard-won policy language. Hosting that material on a platform you do not control means accepting terms of service that can change overnight and access policies that may not survive a geopolitical dispute. A $75 Raspberry Pi in your office closet, backed up to a USB drive, guarantees that your organization's knowledge outlasts every platform pivot and every terms-of-service update. The volunteer who learns to administer it becomes the steward of your institutional memory.