noxway/gitwall repository overview

⁠GitWall

GitWall ist eine moderne, selbst gehostete Git-Plattform aus Europa. Sie kombiniert Repository-Hosting, Pull Requests, Issues, Teams, CI/CD und KI-Funktionen in einer schlanken Anwendung — vollständig auf deiner eigenen Infrastruktur, ohne Abhängigkeit von US-Hyperscalern.

⁠Warum GitWall?

Dein Code gehört dir. Deine Infrastruktur. Deine Regeln.

• 🔒 AES-256-GCM-Verschlüsselung — Repositories liegen verschlüsselt auf deiner Hardware
• 🇪🇺 Kein US-Cloud Act — keine erzwungene Herausgabe an US-Behörden, weil deine Daten nie auf US-Infrastruktur liegen
• 🛡️ DSGVO by Design — keine Drittanbieter-Tracker, keine Analytics, keine externen Fonts
• 📋 NIS2 / BSI-Grundschutz-kompatibel — vollständige Audit-Logs, Secret-Scanning, verschlüsselte Secrets
• 🤖 KI made in EU — Mistral (Paris) oder Ollama lokal, kein OpenAI, kein Azure
• 🚫 Kein Vendor Lock-in — Standard-Git-Protokoll, portierbare Daten, Open Source
• ⚡ Schlanker Stack — Go + HTMX + Bootstrap + PostgreSQL, kein Node.js-Ökosystem, kein Kubernetes-Overhead

⁠Digitale Souveränität konkret

⁠Vorteile gegenüber GitHub, GitLab und Codeberg

GitWall setzt andere Prioritäten: Besitz, Klarheit und Kontrolle statt Feature-Bloat.

⁠Konkrete Pluspunkte von GitWall

• Mehr digitale Souveränität als GitHub: Kein US-Konzern, kein CLOUD Act, keine Abhängigkeit von Microsoft-Produktentscheidungen.
• Weniger Betriebsgewicht als GitLab: Kernfunktionen einer Git-Plattform ohne DevOps-Monolith.
• Mehr eigene Kontrolle als bei Codeberg: Codeberg ist stark als offene Community — GitWall ist stark, wenn du die Plattform selbst besitzen und betreiben willst.
• Eigene Codebasis statt Plattform-Fork: GitWall ist kein umgelabelter Gitea-/Forgejo-Fork, sondern eine eigenständige Plattform mit Fokus auf Sicherheit, Auditierbarkeit und souveränen Betrieb.
• Sicherheit ab Werk: Repositories verschlüsselt, Secrets verschlüsselt, Secret-Scanning schon beim Push.
• KI aus Europa: Mistral (Paris) statt OpenAI — oder vollständig lokal mit Ollama, komplett offline.
• Eigene Oberfläche, eigene Regeln: URL, Deployment, Admin-Zugriffe, Policies und Datenhaltung vollständig in deiner Hand.

⁠Features

• Repository-Hosting mit Git über HTTP und SSH
• Öffentliche und private Repositories
• Pull Requests mit Merge-Flow
• Issues und Kommentare
• Releases, Tags & Branches — Tags erstellen/löschen, CI-Trigger per Tag-Push (on.push.tags)
• Commit-Ansichten und Diffs
• Organisationen, Teams und Berechtigungen
• Admin-Bereich für Nutzer, Repositories, Audit-Log und App-Logs (/-/admin/logs)
• 7 Sprachen: DE, EN, FR, DA, FI, IT, NL
• LeakGuard Secret-Scanning: Pre-Receive-Hook + gitwall/leakguard@v1 CI-Action, 150+ Regeln, Markdown-Summary
• CVE-Sicherheitsscan: Abhängigkeiten auf bekannte CVEs prüfen (OSV.dev) — Cargo.toml/lock, go.mod, package-lock.json, requirements.txt, Gemfile.lock, composer.lock, uv.lock, poetry.lock
• CI/CD-Pipelines mit GitHub-Actions-kompatiblen Workflows
• Native GitWall Workflows (.gitwall/workflows/) — sicherer Ausführungspfad, Trigger nur aus .gitwall/, Migration aus .github/workflows/ mit automatischer Action-Konvertierung
• Visueller Workflow-Editor — Drag-and-Drop Baustein-Editor mit File-Picker, Raw-Block-Support, Live-YAML-Vorschau und KI-Suggest
• Built-in Actions-Registry: gitwall/checkout@v1, gitwall/setup-go@v1, gitwall/setup-python@v1, gitwall/install-packages@v1, gitwall/leakguard@v1 u.v.m.
• Self-registrierende Runner — kein Pre-Shared-Secret, Admin genehmigt im UI
• Repository-Secrets verschlüsselt gespeichert, bei Laufzeit als Umgebungsvariablen injiziert und im Log maskiert
• Rate Limiting & IP-Blacklist: Login-, Registrierungs- und globales Request-Limit konfigurierbar im Admin-Bereich (/-/admin/security), IP/CIDR-Sperrung sofort wirksam ohne Neustart
• KI-Dokumentation: AI liest das Repo und committed DOCS.md direkt auf den Branch
• Optionale KI via Mistral (EU), Ollama (lokal/offline) oder Ollama Cloud: PR-Reviews, Zusammenfassungen, Drafts, Workflow-Suggest

⁠Tech Stack

• Backend: Go 1.22, Chi Router
• Frontend: HTMX, Bootstrap 5
• Datenbank: PostgreSQL
• Deployment: Docker Compose
• TLS: Built-in autocert (Let's Encrypt, kein externer Proxy nötig)
• Storage: AES-256-GCM verschlüsselte Repository-Archive

⁠Schnellstart mit Docker

cp .env.example .env

Dann in .env mindestens setzen:

• POSTGRES_PASSWORD — sicheres Datenbankpasswort
• ENCRYPTION_KEY — 64 Hex-Zeichen (openssl rand -hex 32)
• ACME_DOMAIN — öffentliche Domain, z. B. git.example.com (DNS muss auf den Server zeigen, Ports 80 + 443 müssen offen sein)
• ACME_EMAIL — E-Mail für Let's-Encrypt-Ablaufbenachrichtigungen (optional)

Danach starten (Image wird automatisch von Docker Hub gezogen):

docker compose up -d

Die App ist danach unter https://<ACME_DOMAIN> erreichbar. TLS-Zertifikat wird automatisch von Let's Encrypt bezogen.

⁠CI Runner starten

Der Runner läuft als separater Container und muss einmalig gebaut werden:

docker compose build runner
docker compose up -d runner

Danach erscheint er im Admin-Bereich unter /-/admin/runners als „Pending" — dort einmalig genehmigen, danach beginnt er sofort mit dem Job-Polling.

⁠Lokale Entwicklung

make run

Weitere nützliche Befehle:

• make test
• make dev
• make docker-up
• make gen-key

⁠Für wen ist GitWall gedacht?

GitWall passt besonders gut für:

• Behörden, Verwaltungen und öffentliche Einrichtungen — DSGVO-konform, keine US-Abhängigkeit, NIS2-kompatibel
• Unternehmen mit Compliance-Anforderungen — Volle Kontrolle über Daten und Infrastruktur, BSI-Grundschutz-kompatibel
• Teams in der EU — Kein US-Cloud Act, kein Vendor Lock-in, KI made in Europe
• Entwickler, die Kontrolle wollen — Sensible Repos nicht an externe Plattformen geben müssen
• Alle, die von GitHub/GitLab wegwollen — Bekannter Workflow, Standard-Git-Protokoll, portierbare Daten

⁠CI/CD

GitWall enthält eine eingebaute CI/CD-Engine, die GitHub-Actions-kompatible Workflows versteht.

⁠Workflows

GitWall führt nur Workflows aus .gitwall/workflows/ aus — .github/workflows/ dient nur als Referenz/Migration.

Lege eine Workflow-Datei im Repository ab oder benutze den visuellen Workflow-Editor unter /{owner}/{repo}/actions/editor:

.gitwall/pipeline.yml           # GitWall-native (einfacher Einstieg)
.gitwall/pipeline.gwb           # GitWall BASIC
.gitwall/workflows/ci.yml       # GitWall-native (mehrere Workflows)
.gitwall/workflows/deploy.gwb   # GitWall BASIC (mehrere Workflows)
.github/workflows/ci.yml        # GitHub-Actions-kompatibel (nur lesen, nicht ausführen)

Bestehende .github/workflows/-Dateien lassen sich mit einem Klick migrieren — bekannte Actions wie actions/checkout → gitwall/checkout@v1 werden automatisch konvertiert, unbekannte Actions kommentiert.

Zusätzlich unterstützt GitWall jetzt ein BASIC-ähnliches Workflow-Format (.gwb). Es ist blockbasiert statt YAML-lastig und wird intern in das normale Workflow-Modell kompiliert.

Unterstützte Trigger: push, pull_request, workflow_dispatch, tag

Automatische push-Runs lassen sich per Commit-Message überspringen, z. B. mit #skip-ci, [skip ci] oder [ci skip].

Beispiel in GitWall BASIC:

WORKFLOW "CI"
ON PUSH
PUSH_BRANCH "main"

JOB "build"
  NAME "Build and test"
  RUNS_ON "ubuntu-latest"

  STEP "Checkout"
    USE "gitwall/checkout@v1"
  END STEP

  STEP "Test"
    RUN """
go test ./...
"""
  END STEP
END JOB

String-Builtins für das BASIC-Format: CONTAINS(...), LEN(...), REPLACE(...).

name: CI
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: gitwall/checkout@v1      # Checkout (runner-seitig)
      - uses: gitwall/leakguard@v1     # Secret-Scan (server-seitig, sofort)
        with:
          fail-on-leak: "true"
          min-confidence: "0.75"
      - name: Build
        run: go build ./...
      - name: Test
        run: go test ./...

⁠Built-in Actions

GitWall bringt fertige Actions mit, die direkt in Workflows genutzt werden können:

LeakGuard-Parameter:

• fail-on-leak: "true" — Step schlägt fehl bei Fund (Standard)
• min-confidence: "0.75" — Mindest-Confidence-Schwelle (0.0–1.0)

⁠Workflow-Editor

Der visuelle Editor ist unter /{owner}/{repo}/actions/editor erreichbar:

• Linke Palette: Built-in Actions + Custom Run-Step per Drag & Drop
• Mittlerer Canvas: Jobs als Karten, Steps als Pills — klicken, ziehen, löschen
• Rechte Properties: Name, Shell-Script, Action-Inputs per Formular
• Unten: Live-YAML-Vorschau (direkt editierbar)
• AI-Suggest (bei aktiviertem Mistral): generiert einen passenden Workflow basierend auf Repo-Sprache

⁠Native Build Dependencies

Für native Builds vor gitwall/setup-rust@v1 oder anderen compilierten Abhängigkeiten:

- uses: gitwall/install-packages@v1
  with:
    packages: |
      build-essential
      pkg-config
      libssl-dev
- uses: gitwall/setup-rust@v1

⁠Azure / ACR / AKS

- uses: gitwall/az-login@v1
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- uses: gitwall/acr-build@v1
  with:
    registry-name: myregistry
    image: myapp:${{ github.sha }}

- uses: gitwall/aks-set-context@v1
  with:
    resource-group: rg-prod
    cluster-name: aks-prod

- uses: gitwall/aks-deploy@v1
  with:
    manifests: k8s/

⁠Runner einrichten

Runner registrieren sich automatisch beim Start — kein Pre-Shared-Secret nötig:

1. Runner-Image bauen: docker compose build runner
2. Runner starten: docker compose up -d runner
3. Im Admin-Bereich unter Runners erscheint der Runner als „Pending"
4. Runner genehmigen — danach beginnt er sofort mit dem Job-Polling

Der Runner generiert beim Start einen eigenen Token (gwr_-Prefix), speichert ihn lokal und registriert sich beim Server. Nach Admin-Genehmigung pollt er Jobs per FOR UPDATE SKIP LOCKED atomar ab und führt Steps in einem temporären Verzeichnis aus.

⁠Repository-Secrets

Unter Einstellungen → Secrets eines Repositories kannst du verschlüsselte Secrets anlegen. Sie werden bei Laufzeit als Umgebungsvariablen (${{ secrets.MEIN_TOKEN }}) in jeden Step injiziert und im Log automatisch maskiert.

⁠Lokale Entwicklung mit Runner

export APP_URL=http://localhost:8080
go run .                         # App starten

# Runner-Image bauen
docker compose build runner

# Runner über Admin-UI starten (/-/admin/runners)
# Docker-Socket wird automatisch erkannt (macOS + Linux)

⁠AI-Dokumentation

Unter /{owner}/{repo}/docs findet sich der Docs-Tab. Mit einem Klick auf „Mit AI generieren" (erfordert USE_AI=true + MISTRAL_API_KEY):

1. Mistral liest die Repo-Struktur, README, Manifest-Dateien und wichtige Quelldateien
2. Generiert eine vollständige DOCS.md mit Abschnitten: Overview, Architecture, Getting Started, Configuration, API Reference, Contributing
3. Committed die Datei direkt als DOCS.md auf den aktuellen Branch
4. Rendert das Ergebnis als sauberes Markdown mit automatischem Inhaltsverzeichnis

Bestehende DOCS.md kann manuell editiert und gespeichert werden.

⁠Security-Administration

Unter /-/admin/security können Admins ohne Neustart konfigurieren:

⁠IP-Blacklist

• Einzelne IPs (1.2.3.4) oder CIDRs (10.0.0.0/8) mit Begründung sperren
• Geblockte IPs erhalten HTTP 403, bevor irgendein Handler greift
• Einträge sofort löschen/hinzufügen

⁠Rate Limits

Alle Limits werden nach dem Speichern sofort in den Arbeitsspeicher geladen.

⁠Externe API fuer CI-Runs und Logs

GitWall bringt jetzt eine tokenbasierte JSON-API unter /api/v1 mit. Sie nutzt die bestehenden Access-Tokens aus den Benutzereinstellungen und ist ueber den Admin-Bereich konfigurierbar:

• /-/admin/api → API global aktivieren/deaktivieren
• Optional auf Admin-Tokens beschraenken
• Optional auf oeffentliche Repositories beschraenken

Beispiel: letzte Runs eines Repositories abrufen

curl -H "Authorization: Bearer gw_xxx" \
  https://gitwall.example/api/v1/repos/acme/demo/actions/runs

Logs eines bestimmten Runs:

curl -H "Authorization: Bearer gw_xxx" \
  https://gitwall.example/api/v1/repos/acme/demo/actions/runs/<run-id>/logs

Verfuegbare Endpunkte:

• GET /api/v1/docs
• GET /api/v1/openapi.json
• GET /api/v1/ci/catalog
• GET /api/v1/actions/runs
• GET /api/v1/repos/{owner}/{repo}/actions/runs
• GET /api/v1/repos/{owner}/{repo}/actions/runs/{runID}
• GET /api/v1/repos/{owner}/{repo}/actions/runs/{runID}/logs
• GET /api/v1/repos/{owner}/{repo}/actions/workflows

⁠EnVault Cloud Sync

Zusätzlich kann GitWall als verschlüsselter Cloud-Sync-Endpunkt für EnVault / ev dienen. Benutzer legen eigene Secret Stores an, erhalten dafür separate Store-Tokens und synchronisieren nur den verschlüsselten Vault-Blob — GitWall kann den Inhalt nicht lesen.

• Admin-Schalter: /-/admin/api → EnVault Sync aktivieren/deaktivieren
• Benutzeroberfläche: /settings/envault
• CLI-Setup: ev cloud setup

Endpunkte:

• POST /api/v1/envault/stores
• GET /api/v1/envault/stores
• DELETE /api/v1/envault/stores/{id}
• GET /api/v1/envault/sync/{id}/
• PUT /api/v1/envault/sync/{id}/

⁠Status

GitWall ist produktionsreif für Teams, die digitale Souveränität ernst nehmen. Kernfunktionen, Sicherheit und EU-Compliance stehen im Vordergrund — kein Feature-Bloat, kein US-Cloud Act, kein Vendor Lock-in.

🇪🇺 Self-hosted. Open Stack. Ihre Infrastruktur. Ihre Regeln.