30 kostenlose GitHub-Tools, die 2026 wirklich Probleme lösen: Entwicklung, Büro, Automatisierung

Auf GitHub gibt es jede Woche eine neue Liste mit „Must-have-Open-Source-Tools 2026“. Sterne zeigen nur, dass jemand auf Star geklickt hat – nicht, welche konkrete Aufgabe das Tool für Sie erledigt. Die folgenden 30 Einträge wählen Sie nach Problem, nicht nach Rang: je zehn für Entwicklung, Büro und Automatisierung. Aufgenommen wird nur, was drei Bedingungen erfüllt – läuft auf Ihrer eigenen Hardware, die Lizenz erlaubt privaten Einsatz, und es ersetzt eine klar benennbare Arbeit: Code durchsuchen, Diffs lesen, PDFs zusammenführen, Haushaltsbuch führen, Websites überwachen, Backups wirklich woanders ablegen.

n8n und viele „Open-Source-Panels“ sind verbreitet, aber die Lizenz ist nicht MIT, Apache oder GPL – deshalb fehlen sie hier. Für Flow-Orchestrierung bleiben Activepieces mit MIT-Kern und Node-RED. Image-Tags und Bedingungen ändern sich; vor der Installation LICENSE und README des jeweiligen Repos lesen. Die 30 Tools müssen Sie nicht auf einmal installieren.

So wurde diese Liste gefiltert

Drei Kategorien reichen – kein zusätzliches Raster aus „KI / Produktivität / Geek“.

• Kommandozeile: heute auf der Entwicklungsmaschine installieren – Code suchen, Diffs lesen, Sprachversionen verwalten, APIs ansprechen.
• Desktop oder lokale Notizen: Daten landen zuerst auf Ihrer Festplatte; Sync kommt danach.
• Self-Hosting: Docker Compose aus dem Repo. Admin-Oberflächen an die lokale Loopback-Adresse binden und per SSH in Ihren Browser leiten.

Entwicklung: zehn Repos, die Sie täglich öffnen

Fast alles hier ist Kommandozeile, mit klaren Lizenzen; unter macOS reicht Homebrew. Unter Linux Distribution oder Upstream-Installer – die Befehle bleiben gleich.

1. ripgrep: im Repo nach Inhalt suchen

BurntSushi/ripgrep · Unlicense · CLI

System-grep funktioniert, in großen Repos brauchen Sie aber .gitignore-Respekt, Zeilennummern und Editor-Tempo. Genau das liefert ripgrep. Die VS-Code-Suche nutzt es oft intern; eine CLI-Installation hält Skripte und Editor auf denselben Ignore-Regeln.

macOS: brew install ripgrep, im Repo-Root rg "TODO|FIXME". Wer einmal im Jahr ein kleines Projekt durchsucht, braucht ack oder ag nicht zusätzlich.

2. lazygit: sehen, was sich wirklich geändert hat

jesseduffield/lazygit · MIT · Terminal-UI

Es lehrt kein Git – es legt Staging-Hunks, Branches und letzte Commits auf einen Bildschirm. Hunkweise stagen, stash, reflog – schneller als git status hin und her. Gefährliche Tasten sind sichtbar; vor dem Verlieren von Commits git reset und git revert unterscheiden.

brew install lazygit, im Repo lazygit. Als Ansicht nutzen, nicht als „nie wieder Befehle lernen“.

3. delta: Diffs, die man lesen kann

dandavison/delta · MIT · CLI

Standard-git diff bei großen Änderungen: nur rote und grüne Wände. delta bringt Syntax-Highlighting, Side-by-Side oder inline – weniger Fehler beim Review eigener Commits. Nach brew install git-delta:

git config --global core.pager delta
git config --global interactive.diffFilter "delta --color-only"

Wer schon ein Diff-Tool gewohnt ist, braucht delta nicht nur für neue Farben.

4. GitHub CLI: PRs ohne Browser

cli/cli · MIT · CLI

gh kümmert sich um GitHub: PRs, Checks, Issues, Action-Logs. Die Historie bleibt bei git. Anmeldung mit gh auth login; Token im System-Keychain oder gh-eigenem Credential Store – nicht in der Shell-History oder im Repo.

brew install gh
gh pr create
gh run watch

5. act: Workflows lokal, bevor Sie pushen

nektos/act · MIT · CLI + Docker

act führt GitHub Actions per Docker lokal aus. Workflow ändern: erst act -l für Jobs, dann den betroffenen Job – statt zehnmal pushen bis alles grün ist. brew install act, Docker muss laufen.

Es simuliert typische Linux-Runner, nicht den macOS-Runner von GitHub. Braucht der Workflow Xcode, Signing oder Simulator, ersetzt act keinen echten Mac. Solche Jobs direkt auf dem Mac ausführen.

6. uv: Python-Umgebung ohne drei Schichten Tools

astral-sh/uv · MIT OR Apache-2.0 · CLI

Wenn pip, venv, pyenv und pip-tools parallel laufen, verbringt ein Neuer Tag eins mit „warum importiert das nicht“. uv bündelt Python installieren, venv anlegen und Dependencies in einem Befehlssatz.

brew install uv
uv python install 3.12
uv init
uv add ruff

Hat das Team Poetry oder PDM in Docs und CI verankert, uv nicht parallel einführen, ohne Lockfiles und Anleitung anzupassen.

7. Ruff: Lint und Format aus einer Hand

astral-sh/ruff · MIT · CLI

Es übernimmt vieles von Flake8, isort und Black, schnell genug für Save-Hook und CI. ruff check . für Probleme, ruff format . für Stil. Ruff format und Black nicht im selben Repo – zwei Formatter überschreiben sich.

Regeln in pyproject.toml. Eine Woche mit Defaults, dann nach Fehlalarmen nachschärfen – nicht am ersten Tag alle Plugins aktivieren.

8. mise: Versionen folgen dem Repo

jdx/mise · MIT · CLI

Node 22, Python 3.12, Go 1.23 sollten nicht in jedermanns ~/.zshrc mündlich vereinbart sein. mise legt .mise.toml ins Projekt; im Verzeichnis die verlangte Version, beim Verlassen zurück. Es ersetzt „nvm + pyenv + ein vergessenes asdf“, nicht die Sprache selbst.

Nach brew install mise die Aktivierungszeile aus dem README in die Shell-Konfiguration. Nur das Binary ohne Hook – Versionen wechseln nicht mit dem Ordner.

9. k9s: erst schauen, wenn der Cluster zickt

derailed/k9s · Apache-2.0 · Terminal-UI

Pod startet nicht, Service ohne Endpoints, Logs weg – in kubectl sind das drei bis vier Befehle. k9s packt Namespaces, Pods, Logs und Port-Forward in eine Tastatur-Oberfläche. brew install k9s, dann k9s.

Produktion mit read-only kubeconfig. Löschen und Shell in Container sind einen Tastendruck entfernt – auf geteilten Maschinen kein cluster-admin.

10. Bruno: API-Sammlungen ins Repo

usebruno/bruno · MIT · Desktop

Postman-Sammlungen nur in einem Account – Umgebungen und Beispiel-Requests gehen verloren. Bruno speichert Requests als Text (.bru), reviewbar wie Code. brew install --cask bruno.

Secrets in von Git ignorierte Env-Dateien, nicht in committete .bru. Nutzt das Team schon einen anderen API-Client, keine zweite „nur für mich“-Sammlung anlegen.

Büro: zehn Tools statt Abo

Büro hier heißt: PDF, Notizen, Diagramme, Tabellen, Aufgaben, Haushaltsbuch, Datei-Sync, Scan-Archiv. Was lokal laufen kann, soll nicht zuerst ein Sitzplatz-Abo kosten. Bei Self-Hosting mit „Kern“ und „Enterprise-Verzeichnis“ steht das unten dabei.

11. Stirling-PDF: PDFs nicht auf fremde Websites

Stirling-Tools/Stirling-PDF · Kern MIT, plus proprietäre Verzeichnisse · Self-Hosted

Zusammenführen, Teilen, Drehen, Komprimieren – Verträge gehören nicht auf eine Wegwerf-Webseite. Stirling-PDF bündelt typische PDF-Ops auf eigener Instanz. Die LICENSE im Repo: außerhalb der Verzeichnisse proprietary, saas, engine usw. gilt MIT; existieren diese Ordner, gelten deren eigenen LICENSE-Dateien. Für Teile der Funktionen gibt es separate Produktionsbedingungen.

Vor dem Deploy README zu Image und Tag lesen, dann LICENSE dieses Tags. Privat auf der eigenen Maschine reicht oft; als Dienst für andere oder Weiterverkauf erst die proprietären Verzeichnisse durchlesen. Chinesisches OCR nicht voraussetzen – Standard-Images haben die Sprachpakete nicht immer.

12. SiYuan: Wissensbasis auf eigener Platte

siyuan-note/siyuan · AGPL-3.0 · Desktop / Self-Hosted

Block-Referenzen, bidirektionale Links, lokal-first. Der Inhalt liegt im Datenverzeichnis auf Ihrer Maschine, nicht in einem Account mit halbem Export. Offizieller Sync ist optional kostenpflichtig; eigener Sync kann per S3 in der Doku laufen. AGPL-3.0: privat nutzen und ändern ist ok; als öffentlicher Netzwerkdienst gelten die AGPL-Pflichten.

Web-Kernel an 127.0.0.1 binden. Nicht für Handy-Komfort auf 0.0.0.0 ohne Auth lauschen.

13. Joplin: Web-Clips und verschlüsselter Sync

laurent22/joplin · Client AGPL-3.0 · Desktop / Mobil

Mehr Notizbuch als Block-Editor: Markdown, Web-Clipper, Ende-zu-Ende-Verschlüsselung. Sync-Ziel kann eigener Joplin Server, WebDAV oder Object Storage sein. Repo-Default AGPL-3.0; hat packages/server eine eigene LICENSE, vor Server-Deploy öffnen.

Verlorenes Sync-Passwort – verschlüsselte Notizen bleiben gesperrt. Wiederherstellung im Passwort-Tresor notieren, nicht in der Notiz-App. SiYuan schon als Wissensbasis? Dieselben Notizen nicht nach Joplin spiegeln – zwei Gliederungen divergieren.

14. draw.io Desktop: Architekturdiagramme im Repo

jgraph/drawio-desktop · GPL-3.0 · Desktop

Fluss-, Netz- und Sequenzdiagramme als .drawio (XML) in Git – der Diff ist nicht hübsch, aber nicht in einem PNG-only-Account gefangen. Desktop-Repo aktuell GPL-3.0. Ohne Live-Kursor reicht Desktop, kein eigener Zeichen-Server nötig.

Kein Design-System – Komponenten-Stil und Beschriftung bleiben Team-Sache. Offizielle VS-Code-Erweiterung für schnelle Einzelbearbeitung.

15. Penpot: Design-Dateien selbst archivieren

penpot/penpot · MPL-2.0 · Self-Hosted

UI-Mockups, Komponenten, Specs für Frontend – alles in fremder Cloud: Account weg, nur Screenshots. Penpot self-hosted, Dateien orientiert an offenem SVG/CSS. MPL-2.0. Stack mit Frontend, Backend, PostgreSQL und Redis – für zwei Skizzen allein lohnt der Betrieb selten.

Braucht das Team „Design auf unserer Hardware“, Docker Compose aus dem Repo und einen gelesenen Versions-Pin. Sonst draw.io oder lokale Dateien.

16. Grist: wenn Excel schon Datenbank ist

gristlabs/grist-core · Apache-2.0 · Self-Hosted

Eine Tabelle per Messenger hin und her, Spalten mit Nummern, Status und Notizen vermischt – das ist keine Tabelle mehr, sondern eine DB ohne Constraints. Grist behält die Tabellen-Ansicht, darunter relationale Spalten und Formeln. Kern Apache-2.0.

Kein BI. Große Dashboards und komplexe Rechte: erst Datenmodell säubern, dann Visualisierung. Beim Self-Host Backup der Datenbank, nicht nur ein xlsx-Export.

17. Vikunja: Aufgaben ohne schweres PM-System

go-vikunja/vikunja · AGPL-3.0 · Self-Hosted

Todos, Listen, Boards, Teilen im kleinen Kreis – oft wird gleich ein volles Projektmanagement deployed. Vikunja ist leichter, startet mit SQLite, später PostgreSQL. AGPL-3.0.

Soll Tickets an Repo, Support-Mail und SLA gekoppelt sein, reicht es nicht. Diese Flows im bestehenden System lassen, keine zweite „Task-Wahrheit“ pflegen.

18. Actual: Budget fragt nach dem Umschlag

actualbudget/actual · MIT · Lokal-first

Envelope-Budget: Einkommen zuerst auf Miete, Steuern, Server, Sonstiges. Actual hält Daten lokal, optional eigener Sync. MIT. Bank-Import hängt von Region und Connector ab – automatischer Abruf für alle Konten nicht voraussetzen.

Persönliches oder kleines Team-Budget, keine Steuer-Software, kein Firmen-Hauptbuch. Belege und Rechnungen nach Paperless – PDF-Rechnungen nicht nur als Anhang im Budget-Tool als einzige Kopie.

19. Syncthing: Ordner-Sync ohne fremde Cloud

syncthing/syncthing · MPL-2.0 · Desktop / Server

Zwei Laptops, ein Handy – ein Verzeichnis syncen, ohne Upload ins Netzlaufwerk. Geräte vertrauen per ID, Traffic peer-to-peer. MPL-2.0.

Löschungen syncen mit. Versehentlich auf einem Gerät gelöscht – überall weg. Das ist kein Backup. Wichtige Ordner zusätzlich mit restic verschlüsseln und Versionen behalten.

20. Paperless-ngx: Scans durchsuchbar machen

paperless-ngx/paperless-ngx · GPL-3.0 · Self-Hosted

Verträge, Belege, Lieferscheine in einen Ordner – OCR, Tags, Absender-Archiv. GPL-3.0. Chinesisch braucht Tesseract-Sprachpakete (z. B. chi_sim), Default-Image nicht immer dabei.

Originale brauchen Platte, OCR CPU. Nicht auf derselben 16-GB-Maschine parallel iOS mit Xcode bauen. Admin-UI nicht ins offene Internet; Originalordner und DB gemeinsam sichern.

Automatisierung: zehn Projekte gegen Routinearbeit

Automatisierung hier: ein Flow, eine Benachrichtigung, ein Backup, ein Dependency-Update. Was ein Skript plus cron erklärt, braucht noch keine Orchestrierungsplattform.

21. Activepieces: Flow visualisieren – erst MIT vs. Enterprise klären

activepieces/activepieces · Kern MIT, ee-Verzeichnis separat · Self-Hosted

Formular rein, Tabelle, E-Mail – geht als Skript, zum Übergeben ist ein Diagramm oft klarer. LICENSE: außerhalb packages/ee/ ist MIT; Enterprise-Verzeichnis eigene Enterprise-Lizenz – Produktivnutzung dieser Features nur mit passendem Abo.

n8n mit Sustainable Use License darf man selbst betreiben, verbietet aber Hosting als Dienst für andere – deshalb nicht in den 30. Eigenes n8n ohne externes Angebot? Kein Migrationszwang. Neu aufsetzen mit klarem MIT-Kern: Community-Teil von Activepieces; Enterprise-Features ohne Vertrag nicht aktivieren.

22. Node-RED: eine Nachricht vom Webhook zum nächsten System

node-red/node-red · Apache-2.0 · Self-Hosted

Gut für Events: Webhook, JSON umbiegen, weiter an API oder Queue. Apache-2.0. Flows exportieren nach Git. Tokens im Credential Store, nicht im committeten Flow-JSON.

Große Datenmengen und komplexe Retries nicht auf einer endlos wachsenden Canvas. Dafür Windmill oder Ihr Job-System.

23. Windmill: viele Skripte, eine interne Oberfläche

windmill-labs/windmill · Community vor allem AGPL · Self-Hosted

LICENSE: Default AGPL, zusätzlich Apache-2.0-Dateien, Enterprise-Features proprietär. Passt, wenn ein Python- oder TypeScript-Skript „Kollege füllt Formular, Job läuft“ plus Scheduling werden soll.

Ein cron und ein Skript? Windmill nicht nötig. Sonst vorher Community vs. Enterprise trennen und AGPL-Akzeptanz prüfen.

24. ntfy: Benachrichtigungen nicht nur im Log

binwiederhier/ntfy · Server Apache-2.0 · Self-Hosted

Backup fehlgeschlagen, Zertifikat läuft ab, Build rot – nur im Server-Log ist keine Alarmierung. ntfy per HTTP auf Handy oder Desktop. Server Apache-2.0. Auf öffentlichem ntfy.sh sind Topic-Namen erratbar; self-hosten und Access-Token setzen.

curl -d "backup failed" -H "Authorization: Bearer TOKEN" https://ntfy.example/ops

Token und Domain durch eigene ersetzen. Beispiel-Topic-Namen nicht in Produktion wiederverwenden.

25. Uptime Kuma: erst wissen, dass es down ist

louislam/uptime-kuma · MIT · Self-Hosted

HTTP, TCP, Ping, Zertifikatsablauf – Statusseite für kleine Teams. MIT. Kein Metrik-System; CPU und Latenz-Histogramme gehören zu Prometheus o. Ä., nicht in Kuma gestapelt.

Öffentliche Statusseite verrät interne Hostnamen. Interne Checks hinter LAN oder SSH; nach außen nur, was Nutzer sehen sollen. Alarme an eigenes ntfy.

26. changedetection.io: Seite ändert sich – Sie nicht täglich refreshen

dgtlmoon/changedetection.io · Apache-2.0 · Self-Hosted

Preis, Doku-Absatz, Jobs-Seite, Release Notes – Selektor setzen, bei Änderung melden. Apache-2.0. JavaScript-Seiten brauchen Browser, mehr CPU als statisches HTML – Intervall großzügig.

AGB und robots respektieren. Keine Login-Seiten oder verbotene Inhalte scrapen. Benachrichtigung weiter per ntfy, kein Chat-Bot nur dafür.

27. Renovate: Dependency-Updates als ablehnbare PRs

renovatebot/renovate · AGPL-3.0 · GitHub App / Self-Hosted

Veraltete Lockfiles, weil niemand im Riesen-Diff Breaking Changes sucht. Renovate splittet PRs pro Paket, Config in renovate.json. AGPL-3.0. Öffentliche Repos oft gehostete GitHub App; private ohne Dritt-App → self-host.

In Woche eins kein Auto-Merge für Majors. Dependabot ist GitHub-Produkt, nicht auf dieser Self-Host-Liste; wer es nutzt, muss nicht wechseln.

28. restic: Backup heißt, Restore geübt zu haben

restic/restic · BSD-2-Clause · CLI

Verschlüsselung, Deduplizierung, Ziele lokale Platte, SFTP oder Object Storage. BSD-2-Clause. Syncthing syncet den aktuellen Stand; restic hält historische Snapshots.

restic init --repo /path/to/repo
restic -r /path/to/repo backup "$HOME/Documents"
restic -r /path/to/repo snapshots
restic -r /path/to/repo restore latest --target /tmp/restore-test

Passwort per RESTIC_PASSWORD_FILE in eine Datei außerhalb von Git. Mindestens quartalsweise restore testen – leere Snapshots erkennen.

29. Vaultwarden: Passwort-Server selbst betreiben

dani-garcia/vaultwarden · AGPL-3.0 · Self-Hosted

Implementiert die mit Bitwarden-Clients kompatible Server-API, leichter als der offizielle Server, AGPL-3.0. Community-Implementierung, nicht der offizielle Bitwarden-Server des Unternehmens. Clients bleiben die offiziellen Bitwarden-Apps.

HTTPS Pflicht. Admin-Token nicht ins Repo. Datenverzeichnis sichern und Master-Passwort separat – nur Daten-Backup, Passwort nur im Kopf: bei Hardware-Tot keine Tresor-Wiederherstellung. Nicht ungeschützt auf öffentlichen Ports.

30. IT-Tools: Kleinkram im Browser

CorentinTh/it-tools · GPL-3.0 · Browser / Self-Hosted

Base64, Hash, JWT dekodieren, Cron erklären, Regex – wöchentlich, ohne dubiose Einmal-Webseiten. IT-Tools lokal oder self-hosted. GPL-3.0. Vieles rechnet im Browser.

Produktions-Tokens trotzdem nicht in eine firmenweite Instanz ohne Audit kleben. Lokal eine Kopie reicht.

Was Sie in Woche eins wirklich installieren

Die 30 sind Menü, kein Install-Skript. Erste Woche nur das Folgende – nach sieben Tagen erweitern.

brew install ripgrep lazygit git-delta gh uv ruff mise
git config --global core.pager delta
git config --global interactive.diffFilter "delta --color-only"
uv python install 3.12

Fallstricke beim Self-Hosting

1. Admin-UI an 127.0.0.1, per SSH-Port-Forward auf den Laptop. Gleiches für Uptime Kuma, Vaultwarden, SiYuan, Paperless, Activepieces.
2. Enterprise-Verzeichnisse sind kein Gratis-Klon. Activepieces packages/ee, proprietäre Stirling-Ordner, Windmill Enterprise, Projekte wie AFFiNE (Frontend MIT, Server mit Enterprise-Bedingungen) – in Produktion die jeweilige LICENSE lesen. SiYuan statt AFFiNE-Backend als „gratis Self-Host“ – deshalb diese Wahl.
3. AGPL privat meist unkritisch; als öffentlicher Netzwerkdienst gelten Quellcode-Pflichten. Im Zweifel LICENSE, nicht Marketing „open source“.
4. Sync ist kein Backup. Syncthing überträgt Löschungen; restic behält Snapshots. Tresor-Passwort und Datenverzeichnis getrennt halten.
5. Version pinnen. In Compose den gelesenen Tag, kein schwebendes latest. Vor Upgrade Migrationshinweise des Tags.
6. Secrets nicht in Git. Bruno-Env, Node-RED-Tokens, restic-Passwortdatei, ntfy-Bearer – ignorierte Pfade.

Auf einem Cloud Mac

Die CLI-Gruppe per Homebrew auf dem Mac – wenig RAM. Docker mit OCR, Design-Kollaboration und Flow-Orchestrierung frisst RAM und Disk. 16 GB mit parallel Xcode und Simulator: chinesisches Paperless-OCR oder Penpot mit vollem DB-Stack nicht auf derselben Maschine. PDF und Scans besser auf mehr Platte, ohne Compile-Konkurrenz.

act nutzt Linux-Container und ersetzt keine GitHub Actions mit Xcode. iOS-Build, Signing und Simulator auf dem Mac; im Workflow nur Lint oder Linux-Tests → act lokal vorspielen.

Admin-Oberflächen weiter an Loopback. SSH-Forward vom eigenen Rechner, Port auf lokalen Browser – Vaultwarden oder Kuma nicht auf öffentliche IP mappen. restic-Repo in Object Storage oder auf anderer Platte; der Mac nicht die einzige Kopie. Notizen sowie .mise.toml und Ruff-Config in Git; Passwörter und API-Token nicht.

FAQ

Lohnt sich hohe Sternzahl? Als Argument nein. Sterne zeigen Reichweite, nicht passende Lizenz oder Ihr Problem. Schreiben Sie eine Arbeit auf, die diese Woche wegfallen soll, und wählen Sie aus der Tabelle.

Warum kein n8n? Sustainable Use License, nicht MIT / Apache / GPL. Selbst hosten ohne externes Angebot nutzen viele – kein Migrationszwang für diese Liste. Klarere Alternativen: MIT-Kern von Activepieces oder Apache-2.0 Node-RED.

Alle 30 installieren? Nein. Woche eins nur relevante Zeilen aus „Was Sie in Woche eins wirklich installieren“. Pro Klasse eine Notiz-, Sync-, Orchestrierungs- und Backup-Lösung.

AGPL vs. MIT privat? Nutzen und Ändern auf eigener Maschine: beides ok. Unterschied bei Weitergabe und Netzwerkdienst: AGPL verlangt Quellcode-Pflichten für Netzwerk-Services; MIT vor allem Copyright-Hinweis. Enterprise-Verzeichnisse und proprietäre Zusätze separat lesen – „MIT auf der Repo-Startseite“ beschreibt nicht das ganze Repo.

Ist Self-Hosted Passwort-Tresor sicher? Vaultwarden legt Daten auf Ihrer Platte; HTTPS, Updates, Backup und Passwort-Verwahrung liegen bei Ihnen. Offizielles Bitwarden-Hosting ist anderer Trade-off. Überall: Passwort und Daten-Backup trennen und Restore üben.

Alles auf einem Cloud Mac? CLI-Tools ja. OCR, Penpot und mehrere Datenbanken nicht mit Xcode in 16 GB RAM. Admin per SSH-Forward; restic-Kopien nicht nur auf diesem Mac.