Soft Serve: eigener Git-Server, bedient über SSH
Der leistungsstarke, selbsthostbare Git-Server für die Befehlszeile. Sie können auch einige der folgenden Befehle ausprobieren: Oder Sie können Soft Serve verwenden, um lokale Repositorys zu durchsuchen, indem Sie Soft Browse [Verzeichnis] verwenden oder Soft in einem Git-Repository ausführen.
Auf einen Blick
- Was ist das?
- Das Go-Tool soft-serve (v0.12.2) stellt einen selbst gehosteten Git-Server bereit, dessen Verwaltung, TUI und Dateiansicht vollständig in der SSH-Sitzung leben. Ein Blick auf Setup, Konfiguration, Zugriffssteuerung und Grenzen.
- Für wen ist es gedacht?
- Soft Serve passt für kleine Teams und Infrastruktur-Umgebungen, die einen schlanken Git-Server mit SSH-Verwaltung suchen, etwa als Push-Ziel für GitOps-Werkzeuge. Ungeeignet ist es, wenn Pull-Requests, Code-Review oder ein Web-Interface Pflicht sind.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 15 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Der Probierzugang über ssh git.charm.sh
Ein Git-Server, dessen Interface ein Terminal ist: Soft Serve von Charmbracelet dreht das übliche Bild eines Forges um. Statt einer Weboberfläche bekommt man eine TUI, die per SSH erreichbar ist, dazu Klonen über SSH, HTTP oder das Git-Protokoll. Das Projekt ist in Go geschrieben, steht unter der MIT-Lizenz und zeigt rund 7.200 Sterne auf GitHub.
Wer das Gefühl dafür bekommen will, macht es wie das README vorschlägt und verbindet sich mit ssh git.charm.sh. Mit ssh git.charm.sh -t soft-serve springt man direkt in das Repository im TUI, ssh git.charm.sh repo tree soft-serve gibt den Verzeichnisbaum aus, und ssh git.charm.sh repo blob soft-serve cmd/soft/main.go -c -l druckt eine konkrete Datei mit Syntaxhervorhebung und Zeilennummern. Diese Befehle sind mehr als Gimmicks, sie zeigen die eigentliche Idee: Repositories ansehen, Dateien lesen und Verwaltung laufen alle über dieselbe SSH-Verbindung, die man ohnehin zum Pushen nutzt.
Ein Binary, mehrere Ports: soft serve und das data-Verzeichnis
Ausgeliefert wird Soft Serve als einzelnes Binary namens soft. Es liegt in vielen Paketquellen, etwa per brew install charmbracelet/tap/soft-serve, per winget unter Windows, per pacman auf Arch oder via go install github.com/charmbracelet/soft-serve/cmd/soft@latest. Für Debian, Ubuntu und Fedora betreibt das Projekt eigene Apt- beziehungsweise Yum-Repositories, deren Pakete gleich fertige Systemd-Units mitbringen. Ein Docker-Image wird im README ebenfalls verlinkt.
Der Serverstart braucht nur zwei Voraussetzungen: ein installiertes git und der Aufruf soft serve. Dabei entsteht ein data-Verzeichnis, das Repositories, SSH-Schlüssel und die Datenbank aufnimmt. Der Pfad lässt sich mit SOFT_SERVE_DATA_PATH verschieben, etwa auf /var/lib/soft-serve, und mit SOFT_SERVE_CONFIG_LOCATION zeigt man auf eine vorab angelegte Konfigurationsdatei. Für den ersten Start verlangt das Tool die Umgebungsvariable SOFT_SERVE_INITIAL_ADMIN_KEYS mit einem öffentlichen SSH-Schlüssel, daraus baut es einen Admin-Benutzer mit vollen Rechten, der später umbenannt werden kann.
config.yaml gegen SOFT_SERVE_SSH_LISTEN_ADDR: zwei Konfigurationswege
Nach dem ersten Start liegen alle Einstellungen in config.yaml unterhalb des data-Verzeichnisses. Die vordefinierte Datei nennt den Servernamen, das Logformat mit den Werten json, logfmt und text, die SSH-Listenadresse :23231 samt public_url und key_path, dazu HTTP- und Git-Daemon-Einstellungen. Jede dieser Optionen lässt sich per Umgebungsvariable überschreiben, das Muster ist konsequent SOFT_SERVE_ plus Name in Großbuchstaben: SOFT_SERVE_SSH_LISTEN_ADDR für den Listener, SOFT_SERVE_HTTP_PUBLIC_URL für die beim Klonen genutzte URL, SOFT_SERVE_GIT_MAX_CONNECTIONS für die Zahl gleichzeitiger Git-Daemon-Verbindungen.
Diese Doppelstruktur macht Container-Setups deutlich einfacher, weil man config.yaml nicht in ein Image backen muss. Für die Datenbank stehen SQLite und Postgres zur Wahl, Voreinstellung ist SQLite. Ein bemerkenswertes Detail ist SOFT_SERVE_DEFAULT_REPO: Gibt man einen Repository-Namen an, existiert dieses Repository genau dann, wenn der Server hochgefahren ist, leer und öffentlich, als hätte jemand repo create ausgeführt. Das README empfiehlt das ausdrücklich für GitOps-Tools wie ArgoCD, die beim Bootstrap einen Git-Remote benötigen, etwa aus einem Helm-Chart heraus. Beim erneuten Start gegen dasselbe data-Verzeichnis ist der Vorgang ein No-op.
anon-access, allow-keyless und der RSA-Schlüssel-Hinweis
Die Zugriffssteuerung läuft über SSH-Authentifizierung mit öffentlichen Schlüsseln, doppelte Schlüssel werden laut Dokumentation abgelehnt. Zwei Einstellungen regeln den anonymen Zugang: anon-access bestimmt die Stufe für anmeldefreie Nutzer, von no-access über read-only bis read-write, und allow-keyless entscheidet, ob Verbindungen ohne Schlüssel überhaupt durchgelassen werden. Ist allow-keyless deaktiviert, schlagen HTTP- und git://-Klone fehl. Das README warnt unmissverständlich, dass die Overrides über SOFT_SERVE_ANON_ACCESS und SOFT_SERVE_ALLOW_KEYLESS vollen unauthentifizierten Zugriff geben und nie in einem nicht vertrauenswürdigen Netzwerk freigeschaltet werden dürfen.
Kollaborateure werden per SSH mit ihren öffentlichen Schlüsseln hinzugefügt, Repositories lassen sich als öffentlich oder privat markieren, und für die HTTP-Authentifizierung gibt es nutzerbezogene Access-Tokens. Eine dokumentierte technische Begrenzung betrifft RSA: Wegen eines Problems im Go-Paket x/crypto/ssh funktionieren neue SSH-RSA-Schlüssel nicht, nur ältere mit SHA-1. Moderne ed25519-Schlüssel umgehen dieses Thema komplett.
repo create per SSH oder per git push
Repository-Operationen hängen am Befehl repo, den man in der SSH-Sitzung ausführt: create, delete, rename, description, private, hide, info, list, dazu tree und blob für die Dateiansicht, collab für Mitwirkende, import für das Übernehmen öffentlicher Remotes und mirror für Pull-Mirrors. Der elegantere Weg ist aber das On-Demand-Erstellen: Man schiebt einfach per git push auf eine Remote, die es auf dem Server noch gar nicht gibt, und Soft Serve legt das Repository beim ersten Push an.
Für Automatisierung jenseits von Admin-Befehlen gibt es serverseitige Git-Hooks. pre-receive, update, post-update und post-receive lassen sich pro Repository im hooks-Ordner des jeweiligen Repos ablegen oder global unter dem Datenpfad, das README zeigt ein Beispiel für einen Update-Hook, der Push-Details ausgibt. Webhooks melden Ereignisse wie push, collaborators und branch_tag_create nach außen. In der TUI kopiert ein Tastendruck auf c den Klonbefehl des markierten Repos in die Zwischenablage, sofern das Terminal OSC52 unterstützt.
Wo Soft Serve gegen Gitea verliert
Die Grenzen ergeben sich aus dem Konzept. Es gibt kein Web-Interface, also keine Pull-Requests, kein Issue-Tracking und kein Code-Review in einem Browser. Wer eine Datei ansehen will, braucht eine SSH-Sitzung oder das HTTP-Klonen, und das Ausdrucken großer Dateien über SSH ersetzt kein ordentliches Browsing. Mit 78 offenen Issues und Version v0.12.2 von August 2026 ist das Projekt aktiv, aber erkennbar ein Werkzeug für Kommandozeilen-Anwender, nicht eine Forge-Plattform.
Die naheliegende Alternative ist Gitea. Es bringt eine vollständige Weboberfläche, Pull-Requests, Issues und CI-Anbindung mit, verlangt dafür aber einen laufenden Webdienst, mehr Wartung und deutlich mehr Ressourcen. Soft Serve setzt genau dort an, wo das zu viel ist: ein einzelnes Binary, SSH als Transport und Verwaltungsweg, SQLite als Datenbank. Wer hingesten Repositories bloß hosten und pushen will, etwa hinter einer Firewall oder als Ziel für ArgoCD-Bootstrap, fährt damit leichter als mit jedem Forge.
Redaktionelles Fazit
Soft Serve passt für kleine Teams und Infrastruktur-Umgebungen, die einen schlanken Git-Server mit SSH-Verwaltung suchen, etwa als Push-Ziel für GitOps-Werkzeuge. Ungeeignet ist es, wenn Pull-Requests, Code-Review oder ein Web-Interface Pflicht sind. Vor dem Einsatz lohnt der Probelauf gegen ssh git.charm.sh und ein Blick auf die v0.12.2-Releasenotes, falls Git-LFS eine Rolle spielt.
Community-Notizen