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

📚 Tutorial ⏱ ~35 min read 🧩 4 Parts · 13 Sections Beginner → Intermediate

🎯 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
How to connect AI coding assistants (Claude, Cursor, ChatGPT) to Gitea via MCP

📋 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.

⚠️ One-time warning Every command in this tutorial uses plain text and code you can inspect. No installers phone home, no telemetry, no sign-up required (except your own Gitea server). You stay in control.

✅ Required Software — Server Side

Software	Linux Path	Windows Path
Docker Engine	Required. Install via `sudo apt install docker.io`	Not required (Gitea runs as a native binary)
Docker Compose	Required. Install via `sudo apt install docker-compose-v2`	Not required
Git for Windows	Not needed (Git is built into Docker images)	Required. Download from gitforwindows.org
Administrator / sudo access	Required (to install Docker and run containers)	Required (to register a Windows Service)

✅ 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.

💡 Bottom line for Windows users To run the server: download Git for Windows + the Gitea .exe file. That's it. Two downloads, zero dependencies.
To connect as a developer: install Git for Windows. One download. Done.

💻 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.

📖 Table of Contents

Prerequisites: What You Need (and Don't Need)
Why Build Your Own Git Server?
A Brief History of Version Control
Platform Shootout: Gitea vs GitLab CE vs Forgejo vs GitHub
Architecture for a Small Team
Step-by-Step: Install Gitea on Linux
Step-by-Step: Install Gitea on Windows
The First-Time Setup Wizard
Configuring Your Team Workflow
CI/CD with Gitea Actions
Connecting Windows Dev Machines to Gitea
The Daily Git Cycle Cheat Sheet
AI & Coding Agents: Can You Use Claude, Copilot, and Cursor with Gitea?
What's Next?

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.

💡 The alternative Self-host Gitea on a $5/month VPS. Unlimited repos, unlimited collaborators, unlimited CI minutes. Your code, your server, your rules.

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.

Quiz 1 🧠 Why Self-Host?

Which of the following is NOT a reason to self-host Gitea instead of using GitHub Free?

A. GitHub Free limits private repo collaborators to 3 per repo B. Gitea runs on a Raspberry Pi 4 and uses ~40 MB RAM C. GitHub Free gives you unlimited CI/CD minutes for private repos D. You want full control over your code and data

Correct! GitHub Free gives you only 2,000 Actions minutes/month for private repos — not unlimited. That is NOT a reason to choose GitHub over self-hosting. All other options are valid reasons to self-host.

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.

Feature / Platform	Gitea	GitLab CE	Forgejo	GitHub
RAM Required	~40 MB (idle)	~4 GB (minimum)	~40 MB (idle)	N/A (SaaS)
Install Method	1 binary or Docker	Full stack (Ruby, Postgres, Redis)	1 binary or Docker	Sign up online
Built-in CI/CD	Gitea Actions (GitHub Actions compatible YAML)	GitLab CI (mature, powerful)	Forgejo Actions (forked from Gitea)	GitHub Actions (2,000 min/mo free)
UI Familiarity	1:1 GitHub clone	Different layout, more menus	1:1 GitHub clone	Industry standard
Governance	Community (open)	Commercial (GitLab Inc.)	Community (non-profit, forked from Gitea)	Commercial (Microsoft)
Docker Setup	2 minutes (1 yml file)	20+ minutes (multiple containers)	2 minutes (1 yml file)	N/A
Cost for 4 users	$5/month (VPS) + $0 licensing	$10-20/month (larger VPS) + $0 licensing	$5/month (VPS) + $0 licensing	$16/month (Team plan) + $0 (Free limitations)

⚠️ Honest take GitLab CE is a powerful platform, but its minimum RAM requirement (4 GB) is absurd for a 4-person team. GitLab is designed for enterprises with hundreds of users. For a small team, Gitea or Forgejo are the right choice — they run comfortably on 256 MB RAM and install in 60 seconds.

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.

Quiz 2 🧠 Architecture & Database

For a 4-person team, which database should you use with Gitea and why?

A. Postgres — it's more professional and scales better B. MySQL — it's what most tutorials recommend C. SQLite — zero maintenance, single file, perfectly handles 4 concurrent devs D. MongoDB — it's the fastest option

Correct! SQLite is the right choice for small teams. Gitea natively supports it with zero maintenance — no separate database server needed. You can migrate to Postgres later if your team grows beyond 10+ developers.

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

🔴 Critical 2026 Security Notice Use Gitea v1.26.4 or later. Earlier versions (v1.26.2 and below) have CVE-2026-20896 — an insecure default wildcard in proxy configurations. Always pin a specific version.

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.

✅ Verify it's running docker compose logs -f shows real-time logs. docker compose ps shows the container status. If you see "Web server is ready", you're good.

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.

⚠️ Note This installs Gitea directly as a Windows binary. For production, the Docker-on-Linux method (Section 5) is more robust. This method is ideal for a dev machine or small office setup.

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:

Setting	Recommended Value	Why
Database Type	SQLite3	Zero maintenance. A single file. Perfect for small teams.
Site Title	`Our Team Forge` (or your team name)	Shows in the browser tab and email notifications.
Server Domain	Your server's IP or domain	Used in clone URLs. Set it correctly now — changing it later breaks existing clones.
SSH Server Port	`2222` (Linux/Docker) or `22` (Windows standalone)	On Linux, port 22 is usually occupied by the host SSH server.
Gitea HTTP Port	`3000`	Default. Don't change unless you have a conflict.
Gitea Base URL	`http://your-server-ip:3000/`	Must match the domain and port users will access.

🔴 Critical: Create your admin account NOW On the setup page, scroll down to "Administrator Account Settings" and create your admin account (username, password, email). If you skip this step, the first user who registers on the site will automatically become the administrator — which could be someone else!

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:

Click the + icon in the top navigation → New Organization
Name it your-team-name (e.g., core-team)
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)

💡 Why this works for 4 people With only 4 devs, you want a lightweight process — not the heavyweight enterprise flow. Requiring 1 approval on every PR means code gets reviewed quickly, but nothing breaks main. No one can bypass the process.

Quiz 3 🧠 Branch Protection

Why should a 4-person team set branch protection on the main branch with "Require Pull Request before merging" and "Require 1 approval"?

A. Because GitHub requires it for all repositories B. To ensure every change is reviewed by at least one teammate before reaching main, preventing broken code from being pushed directly C. To slow down development intentionally D. Because Git forces you to use branch protection

Correct! With branch protection, no one can push directly to main. Every change goes through a Pull Request and at least one review. This prevents accidents without slowing down a small team — 1 approval is fast but effective.

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.

#	Command	What It Does
1	`git status`	Check what files changed. Run this constantly to stay oriented.
2	`git add <file>`	Stage specific changes. Use `git add .` only when you're sure everything should go in.
3	`git commit -m "message"`	Take a snapshot locally. Write clear messages: "Fix login redirect bug" not "fix".
4	`git push origin main`	Send your commits to Gitea. Now your teammates can see your code.
5	`git pull origin main`	Get your teammates' latest changes before you start working. Do this every morning.

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

💡 Pro tip for small teams With 4 people, pull before you push — always. If someone else pushed while you were working, Git will ask you to merge. Resolve merge conflicts with your editor's merge tool (VS Code has a great one built-in).

Quiz 4 🧠 Daily Git Workflow

What is the correct order of the 5-command daily Git cycle?

A. commit → add → push → pull → status B. pull → edit → status → add → commit → push C. push → pull → commit → add → status D. status → push → pull → add → commit

Correct! Pull (get latest) → Edit (make changes) → Status (check what changed) → Add (stage) → Commit (snapshot) → Push (send to server). Pull before you push — always!

12. AI & Coding Agents: Can You Use Claude, Copilot, and Cursor with Gitea? Advanced

One of the most common questions from teams switching to a self-hosted Git server is: "Can I still use AI coding assistants?" The short answer is yes — and in some ways, Gitea gives you more control over AI integrations than GitHub does.

Gitea does not have a built-in AI assistant like GitHub Copilot or GitLab Duo. Instead, it exposes a full REST API and supports the Model Context Protocol (MCP), which lets any MCP-compatible AI tool connect to your Gitea instance. This is a fundamentally more open approach — you choose the AI tool, the model, and the policies.

12.1 The Gitea MCP Server — Your AI Gateway

The Gitea MCP Server (gitea-mcp) is an official tool that implements the Model Context Protocol — an open standard that lets AI applications (Claude, Cursor, ChatGPT, Copilot, VS Code) interact with Gitea using natural language. Think of it as a USB-C port for AI: one standard connector that works with any compatible client.

Client	Status	What You Can Do
Cursor	✅ Full support	Create repos, branches, issues, PRs, review code, search — all from the editor
Claude Desktop / Claude Code	✅ Full support	Natural language repo management, issue triage, PR creation, code review
ChatGPT (GPT-5.x / Codex)	✅ Via MCP	Query repos, create and manage issues, read file contents
VS Code (GitHub Copilot Chat)	✅ Via MCP	Copilot can reference Gitea repos when connected via MCP
GitHub Copilot CLI	⚠️ Partial	Works with local git operations; remote Gitea operations require MCP bridge
Claude Cowork / OpenCode	✅ Via MCP	Full agentic coding workflows connected to your Gitea repos

12.2 How to Connect: The 5-Minute Setup

Connecting your AI assistant to Gitea takes exactly four steps:

Step 1: Generate a Personal Access Token in Gitea

Settings → Applications → Manage Access Tokens → Generate Token

Choose the permissions your AI agent needs (read/write on repos, issues, PRs). Copy the token — it's shown only once.

Step 2: Install the Gitea MCP Server

pip install gitea-mcp

Or use uvx gitea-mcp without installing anything (recommended for isolation).

Step 3: Configure Your Client

For Cursor, add to .cursor/mcp.json:

{
  "mcpServers": {
    "gitea": {
      "command": "uvx",
      "args": ["gitea-mcp"],
      "env": {
        "GITEA_URL": "https://your-gitea-server:3000",
        "GITEA_TOKEN": "your-personal-access-token"
      }
    }
  }
}

For Claude Desktop, use the interactive setup:

gitea-mcp init

Claude prompts you for the Gitea URL and token, verifies the connection, and configures claude_desktop_config.json automatically.

For Claude Code, add to ~/.claude.json:

{
  "mcpServers": {
    "gitea": {
      "command": "uvx",
      "args": ["gitea-mcp"],
      "env": {
        "GITEA_URL": "https://your-gitea-server:3000",
        "GITEA_TOKEN": "token"
      }
    }
  }
}

Step 4: Start Using Natural Language

Once connected, you can type things like:

# In Cursor or Claude:
"List all open issues in our repository"
"Create a new branch called fix-auth-bug from main"
"Create a pull request merging fix-auth-bug into main"
"Review the latest PR and suggest improvements"
"What files changed in the last 3 commits?"

12.3 Gitea Actions as AI Agents

Beyond MCP, Gitea can run AI agents directly inside your CI/CD pipelines using Gitea Actions. Two community projects make this possible:

Agent	How It Works	Trigger
Claude Code Gitea Action	Runs Claude Code inside a Gitea Action runner. Claude can respond to comments, review PRs, implement features, and push commits — all from within your CI pipeline.	Mention `@claude` in an issue or PR comment
Cursor Gitea Agent	Integrates Cursor AI as a Gitea Action. Tag `@cursor` on an issue or PR to get AI-powered code review, feature planning, or implementation help.	Mention `@cursor` in an issue or PR comment

Example workflow for .gitea/workflows/claude.yml:

name: Claude Code Assistant
on:
  issue_comment:
    types: [created]

jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: markwylde/claude-code-gitea-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          gitea_token: ${{ secrets.GITEA_TOKEN }}
          trigger_phrase: "@claude"

When someone comments @claude Review this PR please on a pull request, the action triggers Claude to analyze the code, post review comments, and even push fixes.

12.4 tea-skills — Agent Skills for the CLI

The tea-skills project packages Gitea/Forgejo workflows as installable skills for Claude Code and other agent CLIs. It uses the tea CLI (Gitea's official command-line tool) under the hood:

# Install tea-skills as a Claude Code plugin
claude plugin marketplace add deevus/tea-skills
claude plugin install tea@tea-skills

# Now your agent can handle issues, PRs, milestones, labels
"List all open issues tagged 'bug'"
"Create a milestone for the next sprint"
"Assign all priority-P1 issues to me"

12.5 What About GitHub Copilot?

GitHub Copilot works primarily with GitHub.com. It does not natively support self-hosted Git servers like Gitea. However, there are two workarounds:

Local code completion works fine — Copilot in VS Code/Neovim/JetBrains completes code based on your local files. It doesn't care where the Git remote lives. All the AI code suggestions work as normal.
MCP bridge to Copilot CLI — For agentic Copilot features (Copilot CLI, Copilot agent mode), you can route Gitea operations through the MCP server. Copilot interacts with Gitea the same way it would with GitHub — it just talks to your server instead.

⚠️ Reality check for Copilot users Copilot's deep GitHub integration (PR summaries, code review, Actions insights) only works with GitHub.com. If you're deeply invested in Copilot Enterprise features, switching to a self-hosted Gitea means losing those. The trade-off: you gain full control, unlimited collaborators, and zero per-seat costs. For most 4-person teams, local code completion + MCP integration covers 95% of what you need.

12.6 What About GitLab Duo?

GitLab Duo AI features (Code Suggestions, Duo Chat, vulnerability explanation) are built natively into GitLab's paid tiers (Premium and Ultimate). They work only with GitLab.com or GitLab Self-Managed instances with a valid subscription. Gitea does not have a native equivalent — but the MCP approach lets you use any AI tool of your choice rather than being locked into a vendor-specific AI.

💡 The open advantage Gitea's approach to AI is fundamentally different from GitHub and GitLab. Rather than bundling a proprietary AI assistant you have to pay for per-seat, Gitea gives you an open MCP interface that works with any AI provider. You choose the model (Claude, GPT, Gemini, local open-source), the client (Cursor, Claude, VS Code), and the security policies. No vendor lock-in. No per-seat AI fees.

Quiz 5 🧠 AI & Coding Agents with Gitea

What is the MCP (Model Context Protocol) in the context of Gitea?

A. A proprietary Gitea-only AI assistant B. An open protocol that lets AI tools like Claude, Cursor, and ChatGPT interact with Gitea through a standard interface C. A replacement for Git itself D. A Microsoft-only protocol that only works with Copilot

Correct! MCP is an open standard — like a USB-C port for AI. Gitea's MCP server lets any MCP-compatible client (Claude, Cursor, ChatGPT, Copilot CLI) manage repos, issues, PRs, and more through natural language.

Quiz 6 🧠 Gitea vs GitHub for AI

Which statement about AI coding assistants and Gitea is true?

A. You cannot use any AI coding tool with Gitea — you must use GitHub or GitLab B. Gitea has a built-in AI assistant called Gitea Duo that rivals GitHub Copilot C. Local code completion (Copilot in VS Code) works fine with Gitea repos, and MCP extends agentic features to Gitea for tools like Claude and Cursor D. Gitea supports Copilot natively with full PR summary and code review features

Correct! Local AI code completion works regardless of where your Git remote is. For agentic features (PR management, issue triage, code review), Gitea's MCP server bridges the gap, letting tools like Cursor and Claude interact with your repos.

13. 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.

🏆 Key Takeaways

Self-hosting Git gives you unlimited repos, unlimited collaborators, and full control — for the cost of a $5/month VPS.
Gitea is the sweet spot for small teams: GitHub-compatible UI, 40 MB RAM, 60-second Docker install.
SQLite is all you need for 4 people. Don't over-engineer with Postgres until you have to.
Branch protection (require PR + 1 approval) is the single most important setting for code quality in a small team.
Gitea Actions uses GitHub Actions syntax — zero learning curve if you've used GitHub CI before.
The daily Git cycle is just 5 commands: pull → edit → add → commit → push.