Build Your Own GitHub: Self-Hosted Git for a 4-Person Team From zero to a running Gitea server with full CI/CD — no DevOps experience required

🎯 What You'll Learn

• Why you might want a self-hosted Git server instead of GitHub/GitLab SaaS
• How version control evolved — and why it matters
• How to compare Gitea, GitLab CE, Forgejo, and GitHub for your needs
• How to deploy Gitea on Linux with Docker Compose (production-ready)
• How to install and run Gitea on Windows as a service
• How to set up branch protection, organizations, and CI/CD pipelines for a small team
• The 5-command daily Git cycle every developer needs

📋 Before You Begin

• Basic familiarity with Git (you've run git commit before)
• A server or VPS (for Linux path) OR any Windows 10/11 machine (for Windows path)
• Comfort with the command line — you'll be running commands, not clicking buttons

0. Prerequisites: What You Need (and Don't Need) Beginner

Before we begin, let's be crystal clear about what software you must have installed — and what you can safely ignore.

✅ Required Software — Server Side

✅ Required Software — Developer Machines (All 4 Team Members)

Each developer who will use the Gitea server needs these on their local machine:

• Git for Windows — Download from gitforwindows.org. This installs both Git and a Bash-like terminal (Git Bash) that works on Windows.
• A code editor — VS Code (recommended), Notepad++, or any text editor. Nothing special required — Git works from the command line regardless of your editor.
• SSH client — Built into Windows 10/11. Open PowerShell and type ssh to verify. No installation needed.

🚫 What You Do NOT Need

This list surprises most people. You can skip installing all of these:

• No Node.js — Gitea is written in Go (compiled), not JavaScript. No runtime required.
• No Python — Not needed for Gitea. (Only required if your CI pipeline uses Python.)
• No Go compiler — Gitea ships as a pre-compiled binary. You don't need to build anything.
• No database server — SQLite is built into Gitea. No separate MySQL, Postgres, or MSSQL setup.
• No web server (Apache/Nginx) — Gitea includes its own HTTP server. Add a reverse proxy only if you want HTTPS later.
• No WSL (Windows Subsystem for Linux) — The Windows path runs Gitea as a native Windows binary. WSL is optional but not required.

💻 Minimum Hardware Requirements

Gitea is famously lightweight. Here's what you actually need:

• CPU: 1 core (any modern processor, including ARM like Raspberry Pi)
• RAM: 256 MB minimum (Gitea itself uses ~40 MB at idle; the OS needs the rest)
• Disk: 1 GB free for Gitea + OS overhead. Actual repo storage depends on your projects, but source code is mostly text — 100 MB can hold years of commits.
• OS: Linux (any distro with Docker) or Windows 10/11 (Pro, Home, or Enterprise — all work)

A $5/month VPS (1 GB RAM, 1 core, 25 GB SSD) can comfortably serve dozens of developers and run CI pipelines.

1. Why Build Your Own Git Server? Beginner

If your team is 4 people, GitHub Free sounds like a good deal — unlimited public and private repositories, right? But here's what it doesn't tell you:

• Private repos on GitHub Free are limited to 3 collaborators per repo. Your 4-person team hits the wall immediately.
• GitHub Actions on the Free plan gives you 2,000 minutes/month across both public and private repos. One good CI pipeline burns through that in days.
• Your code lives on someone else's machine. For startups building proprietary algorithms, client projects, or compliance-sensitive software, that's a non-starter.
• Per-seat pricing scales fast. GitHub Team is $4/user/month × 4 = $192/year. Not huge — but when you add CI minutes, storage, and premium features, it adds up.

Gitea is a lightweight, open-source Git service written in Go. It feels exactly like GitHub — Issues, Pull Requests, Code Reviews, Actions, Wikis — but runs on hardware you control. A Raspberry Pi 4 can serve a 4-person team without breaking a sweat.

2. A Brief History of Version Control Beginner

To appreciate what Gitea does, it helps to understand how we got here. Version control went through three eras:

Era 1: Local Version Control

In the early days, developers copied files into timestamped directories (project-backup-2024-01-01, project-backup-2024-01-02...). Tools like RCS (Revision Control System) used local patch files to track changes — but only on a single machine. If that hard drive died, your entire project history vanished.

Era 2: Centralized Version Control (CVCS)

Systems like CVS, Subversion (SVN), and Perforce introduced a central server that held the canonical repository. Developers "checked out" files, edited them, and "checked in" changes. The server was the single source of truth.

This was a leap forward, but it had a fatal flaw: if the server went offline, nobody could commit. If the server's hard drive crashed without a backup, the entire project history was lost.

Era 3: Distributed Version Control (DVCS) — Git (2005)

Linus Torvalds built Git for the Linux kernel development workflow. The breakthrough: every developer has a complete copy of the entire repository — full history, all branches, all tags — on their local machine.

Local Machine ──push──▶ Central Server (Gitea)
     ◀──pull/fetch──
    (full history)      (full history + collaboration hub)

If the central server dies, any developer's machine can restore it. This is the world Gitea lives in — the Git protocol is already distributed; Gitea just adds the collaboration layer (Issues, PRs, CI) on top.

3. Platform Shootout: Gitea vs GitLab CE vs Forgejo vs GitHub Intermediate

If you're going to self-host, which platform do you choose? Here's an honest comparison for a 4-person team.

The Analogy

Think of GitHub as a luxury hotel — everything is taken care of, but you pay per night and follow their rules. GitLab CE is a full-service office building with heating, security, and a cafeteria — great for 50+ people but overkill (and power-hungry) for 4. Gitea and Forgejo are a cozy flat you own — small, cheap, and fully under your control.

Verdict for this tutorial: Gitea. It's the most mature, has the largest community, natively supports GitHub Actions-compatible CI/CD, and the UI will be instantly familiar to anyone who's used GitHub.

4. Architecture for a Small Team Intermediate

For 4 people, you do not need Kubernetes, load balancers, or high-availability clusters. A single machine running Docker Compose is the right architecture.

Networking Layout

Internet ──▶ [Your VPS / Server]
                │
                ├── Port 3000 (Web UI)
                ├── Port 2222 (SSH for Git operations)
                │
                └── Docker Compose
                      │
                      ├── gitea/gitea:1.26.4
                      └── (optional) postgres:16

Database Decision: SQLite vs Postgres

For 4 people, SQLite is perfect. Gitea's SQLite support stores the entire database in a single file (/data/gitea/gitea.db). Zero maintenance. Zero configuration. Zero extra containers.

Postgres only becomes necessary when you have:

• 10+ concurrent developers
• Multiple repositories with 50,000+ commits each
• High-frequency CI/CD (hundreds of pipeline runs per day)

For a 4-person team, SQLite handles everything effortlessly. You can migrate to Postgres later if you grow.

Storage Layout

./gitea-data/
  ├── data/        # Database (SQLite), avatars, attachments
  ├── git/         # All your Git repositories (bare repos)
  └── ssh/         # SSH keys for your team

Backing up Gitea means backing up this single folder. That's it.

5. Step-by-Step: Install Gitea on Linux Intermediate

This is the recommended path for production use. We'll use Docker Compose for automatic restarts, easy updates, and clean separation.

Prerequisites

Ensure your Linux server has Docker and Docker Compose installed:

sudo apt update && sudo apt install docker.io docker-compose-v2 -y

Step 1: Create the Project Directory

mkdir ~/gitea && cd ~/gitea

Step 2: Create docker-compose.yml

version: '3.8'
services:
  server:
    image: gitea/gitea:1.26.4
    container_name: gitea-server
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    volumes:
      - ./gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"   # Web interface
      - "2222:22"     # SSH (use 2222 to avoid conflict with host SSH)

Step 3: Launch Gitea

docker compose up -d

Gitea is now running. Open your browser to http://your-server-ip:3000.

6. Step-by-Step: Install Gitea on Windows Intermediate

If you don't have a Linux server, or you want to run Gitea on a Windows machine as a lightweight team server, here's the manual path. No Docker required.

Prerequisites

• Git for Windows — download from gitforwindows.org
• Administrator access on your Windows machine

Step 1: Download Gitea

Go to dl.gitea.com/gitea/ and download the latest Windows executable for your architecture (e.g., gitea-1.26.4-windows-4.0-amd64.exe). Rename it to gitea.exe.

Step 2: Create the Directory Structure

C:\gitea\
  ├── gitea.exe
  ├── custom\
  └── data\

Step 3: Run Gitea (First Time)

Open an Administrator Command Prompt or PowerShell:

cd C:\gitea
.\gitea.exe web

Gitea starts in the foreground. Visit http://localhost:3000 — you should see the setup wizard. Press Ctrl+C to stop it for now.

Step 4: Register Gitea as a Windows Service

Run this command as Administrator to make Gitea start automatically on boot:

sc.exe create "Gitea" binPath="C:\gitea\gitea.exe web" start=auto
sc.exe start Gitea

Gitea now runs as a background Windows service, restarting automatically if the machine reboots.

7. The First-Time Setup Wizard Beginner

When you load Gitea for the first time (at http://your-server:3000 or http://localhost:3000), you'll see the setup wizard. Configure these settings for your 4-person team:

8. Configuring Your Team Workflow Intermediate

8.1 Organization Structure

Don't clutter your Gitea dashboard with individual repos under personal namespaces. Instead, create an Organization for your team:

1. Click the + icon in the top navigation → New Organization
2. Name it your-team-name (e.g., core-team)
3. Add all 4 members with appropriate roles

Now all repositories live under your-server:3000/core-team/project-x instead of your-server:3000/personal/project-x. This gives everyone consistent access.

8.2 Branch Protection (The Crown Jewel)

For a small team, the biggest risk is someone force-pushing to main or merging broken code. Branch protection prevents this.

Navigate to: Settings → Branches → Branch Protection Rules → Add Rule

Configure for the main branch:

• Enable push protection: Only whitelisted users/teams can push directly
• Require Pull Request before merging: No direct commits to main
• Require approvals: Set to 1 (with 4 people, 1 reviewer is enough; 2 might be too slow)

9. CI/CD with Gitea Actions Advanced

Gitea Actions uses GitHub Actions-compatible YAML syntax — so if you've written a .github/workflows file before, you already know how to write Gitea Actions. Gitea runs its own act_runner (a lightweight runner binary) to execute pipelines.

Setting Up the Runner

First, add a runner from the Gitea web UI: Settings → Actions → Runners → Create New Runner. Gitea gives you a registration token. Then, on your server:

docker run -d \
  --name gitea-runner \
  -e GITEA_INSTANCE_URL=http://server:3000 \
  -e GITEA_RUNNER_REGISTRATION_TOKEN=YOUR_TOKEN_FROM_UI \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitea/act_runner:latest

Example Pipeline: Test & Deploy

Create .gitea/workflows/ci.yml in your repository:

name: Test and Deploy
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production..."

Gitea Actions automatically picks up this file and runs the pipeline on every push. The syntax is identical to GitHub Actions — no learning curve.

10. Connecting Windows Dev Machines to Gitea Beginner

Your 4-person team is likely on Windows laptops. Here's how they connect to the Gitea server.

Step 1: Install Git for Windows

Each developer downloads and installs Git from gitforwindows.org. During installation:

• Choose "Use Visual Studio Code as default editor" (or their preferred editor)
• Select "Git from the command line and also from 3rd-party software" for PATH integration

Step 2: Introduce Yourself to Git

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Step 3: Clone Using HTTPS

From the repository page in Gitea, copy the HTTPS clone URL and run:

git clone http://your-server-ip:3000/core-team/project-x.git

Windows will prompt for credentials. Type the Gitea username and password. Git for Windows caches credentials securely so you don't have to type them every time.

11. The Daily Git Cycle Cheat Sheet Beginner

Here's the 5-command rhythm every developer on your team needs to know. Print this, tape it to your monitor.

The Full Daily Workflow

# Morning: get everyone's latest changes
git pull origin main

# Make changes in your editor...

# Check what you changed
git status

# Stage the changes
git add .

# Commit with a clear message
git commit -m "Add user authentication middleware"

# Push to Gitea so your team can see it
git push origin main

12. What's Next? Advanced

You now have a running Gitea server with repositories, team structure, branch protection, CI/CD, and a team that knows the daily workflow. Here's what to tackle next:

• SSH Key Authentication — Replace HTTPS password prompts with SSH keys for a smoother experience. Go to Settings → SSH Keys in Gitea.
• Backup Strategy — Schedule nightly backups of the ./gitea-data folder to an external location using rsync or a cron job.
• HTTPS with Let's Encrypt — Add a reverse proxy (Caddy or Nginx) with automatic TLS certificates so your Gitea server runs on HTTPS.
• Migrate from GitHub — Gitea can import repositories from GitHub, GitLab, Bitbucket, and other Git services directly from the UI.
• Scale to 10+ People — When your team grows, migrate SQLite to Postgres (Gitea has a built-in migration tool) and consider adding a second runner for CI.