APAC Self-Hosted Git Guide 2026: Gitea, Forgejo, and Sourcehut for Data Sovereignty

Why APAC Teams Choose Self-Hosted Git

APAC engineering teams that rely exclusively on GitHub, GitLab SaaS, or Bitbucket Cloud store their source code — the primary IP of most technology businesses — on infrastructure controlled by US-headquartered vendors subject to US jurisdiction, outage risk, and pricing changes. For APAC organizations in regulated industries (financial services, healthcare, defense), this creates compliance friction with data sovereignty requirements in Singapore, South Korea, Indonesia, and China.

Self-hosted Git platforms address this by running the complete Git hosting stack — repositories, code review, CI/CD, and package registries — on APAC-controlled infrastructure: on-premise data centers, private cloud VMs, or air-gapped networks.

Three platforms cover the APAC self-hosted Git spectrum:

Gitea — lightweight self-hosted Git with GitHub-compatible API, pull requests, and LDAP/SSO integration for APAC enterprise teams.

Forgejo — community-governed Gitea fork with ActivityPub federation and no commercial entity in the governance chain.

Sourcehut — minimalist software forge with email-based code review, mailing list collaboration, and multi-OS CI for APAC open-source and systems programming teams.

APAC Data Sovereignty and Git Hosting

Regulatory context by APAC market

APAC Data Sovereignty Requirements for Source Code:

Singapore (MAS TRM 2024):
  Financial institutions: source code is IT asset
  Cloud deployment: must document where code is stored
  Self-hosted option: code remains in SG data center
  → Gitea/Forgejo on SG cloud VM satisfies MAS TRM

South Korea (ISMS-P):
  Personal data processing code: domestic residency preferred
  Security-critical systems: on-premise audit requirement
  → Gitea in KR colocation facility

Indonesia (GR 71/2019):
  Strategic data: must reside in Indonesia
  Cloud providers: Kominfo-certified list required
  → Self-hosted Git on Kominfo-certified APAC cloud

China (DSL/PIPL):
  Source code touching Chinese user data: domestic residency
  Cross-border transfers: CAC assessment required
  → Gitea/Forgejo on CN ICP-licensed infrastructure

Japan (FISC Guidelines):
  Financial systems: source code auditability requirement
  → Gitea with LDAP/AD integration for JP enterprise

Self-hosted vs SaaS Git: APAC decision matrix

Dimension             SaaS (GitHub/GitLab)     Self-Hosted (Gitea/Forgejo)

Data location         Vendor data centers       APAC team-controlled
Compliance burden     Vendor SOC2/ISO certs     APAC team manages compliance
Uptime SLA            99.9% (GitHub SLA)        APAC team's infra SLA
Operational burden    None                      APAC team maintains
Cost model            Per-user monthly          Infrastructure only
Feature velocity      Vendor roadmap            Community + APAC custom
API compatibility     GitHub/GitLab native      Gitea GitHub-compatible API
Disaster recovery     Vendor responsibility      APAC team responsibility

Gitea: APAC Lightweight Self-Hosted Git

Gitea installation — APAC Docker deployment

# APAC: Deploy Gitea via Docker Compose

# docker-compose.yml (APAC Gitea deployment)
version: '3.8'

services:
  apac-gitea:
    image: gitea/gitea:1.22-rootless
    container_name: apac-gitea
    restart: always
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=apac-gitea-db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=${GITEA_DB_PASSWORD}
      - GITEA__server__DOMAIN=git.apac-corp.com
      - GITEA__server__SSH_DOMAIN=git.apac-corp.com
      - GITEA__server__ROOT_URL=https://git.apac-corp.com/
      - GITEA__security__SECRET_KEY=${GITEA_SECRET_KEY}
    volumes:
      - apac-gitea-data:/var/lib/gitea
      - /etc/timezone:/etc/timezone:ro
    ports:
      - "3000:3000"
      - "2222:2222"  # APAC SSH git push

  apac-gitea-db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=${GITEA_DB_PASSWORD}
      - POSTGRES_DB=gitea
    volumes:
      - apac-gitea-db:/var/lib/postgresql/data

volumes:
  apac-gitea-data:
  apac-gitea-db:

# APAC: Deploy
# docker-compose up -d
# → Gitea running at https://git.apac-corp.com
# → Initial setup wizard at first visit

Gitea APAC LDAP/AD integration

; APAC: app.ini configuration for enterprise LDAP authentication
; /var/lib/gitea/gitea/conf/app.ini

[server]
DOMAIN           = git.apac-corp.com
ROOT_URL         = https://git.apac-corp.com/

[security]
SECRET_KEY       = <APAC_GENERATED_SECRET>
INTERNAL_TOKEN   = <APAC_GENERATED_TOKEN>

[service]
DISABLE_REGISTRATION              = true  ; APAC: only LDAP users
ALLOW_ONLY_EXTERNAL_REGISTRATION  = true

; APAC: Configure via Gitea admin panel: Site Admin → Authentication
; Authentication source type: LDAP (via BindDN)
; Host: apac-ad.corp.local | Port: 636 (LDAPS)
; Bind DN: cn=gitea-svc,ou=serviceaccounts,dc=apac-corp,dc=com
; User search base: ou=engineering,dc=apac-corp,dc=com
; User filter: (&(objectClass=person)(memberOf=cn=APAC-Dev,ou=groups,dc=apac-corp,dc=com))
; Username attribute: sAMAccountName
; Email attribute: mail
; Admin filter: memberOf=cn=APAC-GitAdmin,ou=groups,dc=apac-corp,dc=com

Gitea Actions — APAC CI/CD pipeline

# APAC: .gitea/workflows/apac-ci.yml
# GitHub Actions-compatible syntax, runs on Gitea Actions runner

name: APAC CI Pipeline

on:
  push:
    branches: [main, 'apac/**']
  pull_request:
    branches: [main]

jobs:
  apac-test:
    runs-on: ubuntu-latest  # or self-hosted APAC runner label

    steps:
      - uses: actions/checkout@v4

      - name: APAC — Set up PHP 8.3
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: pdo_mysql, redis

      - name: APAC — Install dependencies
        run: composer install --prefer-dist --no-interaction

      - name: APAC — Run test suite
        run: ./vendor/bin/pest --parallel
        env:
          DB_CONNECTION: sqlite
          DB_DATABASE: ':memory:'

      - name: APAC — Static analysis
        run: ./vendor/bin/phpstan analyse --memory-limit=512M

Forgejo: APAC Community-Governed Git Platform

Forgejo migration from Gitea — APAC zero-downtime

# APAC: Migrate from Gitea to Forgejo (drop-in replacement)
# Forgejo is binary-compatible — same data directory, same config

# Step 1: APAC — Backup Gitea data
docker exec apac-gitea gitea dump -c /var/lib/gitea/gitea/conf/app.ini \
  --file /tmp/apac-gitea-backup-$(date +%Y%m%d).zip

# Step 2: APAC — Pull Forgejo image (same structure, different vendor)
docker pull codeberg.org/forgejo/forgejo:7.0-rootless

# Step 3: APAC — Update docker-compose.yml image reference
# Change: gitea/gitea:1.22-rootless
# To:     codeberg.org/forgejo/forgejo:7.0-rootless

# Step 4: APAC — Restart with Forgejo
docker-compose up -d

# APAC result:
# - All repositories intact (same data directory)
# - All users, teams, and permissions preserved
# - All webhooks and integrations continue working
# - GitHub-compatible API unchanged
# → APAC teams notice no difference; admin sees Forgejo branding

Forgejo ActivityPub federation — APAC cross-instance

Forgejo Federation (experimental — APAC roadmap 2026):

Scenario: APAC multi-entity organization with separate Forgejo instances
  - git.apac-sg.corp.com (Singapore entity)
  - git.apac-jp.corp.com (Japan entity)
  - git.apac-kr.corp.com (Korea entity)

Without federation:
  → APAC devs need accounts on each instance
  → Cross-instance PRs require manual patch export/import
  → No unified APAC issue tracking across instances

With Forgejo federation:
  → APAC dev on SG instance follows JP repository
  → APAC SG dev submits PR to JP instance from SG account
  → Issues federate across APAC instances via ActivityPub
  → No centralized APAC Git server required

Status: Experimental in Forgejo 7.x (2026)
APAC recommendation: test in non-production APAC environments

Sourcehut: APAC Email-Based Code Review

Sourcehut email patch workflow — APAC contribution flow

# APAC: Contributing to a Sourcehut-hosted APAC project

# Step 1: APAC — Clone the repository
git clone https://git.sr.ht/~apac-maintainer/apac-project

# Step 2: APAC — Create a feature branch
git checkout -b apac/feature-payment-gateway-sg

# Step 3: APAC — Develop and commit
git add .
git commit -m "Add Singapore PayNow payment gateway integration"

# Step 4: APAC — Configure git send-email for Sourcehut
git config --global sendemail.smtpserver mail.sr.ht
git config --global sendemail.smtpuser [email protected]
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpserverport 587

# Step 5: APAC — Send patch to project mailing list
git send-email --to=~apac-maintainer/[email protected] HEAD~1

# APAC result:
# → Patch arrives at mailing list as email
# → Maintainer replies "LGTM, applying" or requests APAC changes
# → No web UI pull request created; all APAC review via email thread

Sourcehut builds.sr.ht — APAC multi-OS CI

# APAC: .build.yml — Sourcehut CI for cross-platform APAC project

image: alpine/edge
packages:
  - go
  - make
sources:
  - https://git.sr.ht/~apac-maintainer/apac-cli-tool
tasks:
  - apac-build: |
      cd apac-cli-tool
      make build GOOS=linux GOARCH=amd64
      make build GOOS=darwin GOARCH=arm64   # APAC: macOS M-series
      make build GOOS=windows GOARCH=amd64

# APAC: Also trigger FreeBSD build for APAC BSD-running systems
---
image: freebsd/latest
packages:
  - go
sources:
  - https://git.sr.ht/~apac-maintainer/apac-cli-tool
tasks:
  - apac-bsd-build: |
      cd apac-cli-tool
      gmake build

# Sourcehut runs both jobs and reports APAC status to the mailing list

APAC Self-Hosted Git Selection Guide

APAC Team Profile                    → Platform    → Why

APAC enterprise with LDAP/SSO        → Gitea        LDAP/AD/SSO;
(compliance, private cloud)          →              GitHub API compat;
                                                    robust APAC ecosystem

APAC team with OSS governance policy → Forgejo       Community governed;
(no commercial vendor dependency)    →              Gitea API compat;
                                                    ActivityPub roadmap

APAC open-source maintainer          → Sourcehut    Email-based review;
(systems/security/crypto projects)   →              multi-OS CI;
                                                    minimal APAC footprint

APAC team needing enterprise GitLab  → GitLab CE     Full DevSecOps;
(MR approvals, DAST, registries)     →              self-managed APAC;
                                                    complex APAC pipelines

APAC team wanting managed SaaS       → GitHub/       Managed APAC infra;
(speed over sovereignty)             → GitLab SaaS   no APAC ops burden

Related APAC DevOps Resources

For the CI/CD pipeline tools (Tekton, Buildkite, Gradle, GitHub Actions) that integrate with self-hosted APAC Git platforms for APAC build automation, see the APAC CI/CD platform guide.

For the GitOps delivery tools (Flux, ArgoCD, Pulumi) that deploy from APAC Git repositories to APAC Kubernetes clusters, see the APAC GitOps and IaC guide.

For the container security and supply chain tools (Cosign, Sigstore, Syft, Grype) that validate artifacts from APAC Git-based pipelines, see the APAC DevSecOps and container supply chain guide.