air: Live-Reload für Go, konfiguriert über .air.toml und build.entrypoint
Live-Neuladen für Go-Apps. Das alte Feld „build.bin“ ist veraltet und wird in einer zukünftigen Version entfernt. Bevorzugen Sie daher in Zukunft das Einstiegspunktformular.
Auf einen Blick
- Was ist das?
- air ist ein in Go geschriebenes Kommandozeilenwerkzeug, das ein Go-Projekt beobachtet und bei Dateiänderungen neu baut und startet. Der Überblick behandelt die Installationswege, die Konfiguration, die Ablösung von build.bin durch build.entrypoint, Watch-Regeln, den Proxy-Modus und den Docker-Betrieb.
- Für wen ist es gedacht?
- air passt zu Go-Entwicklern, die während der Arbeit nicht ständig zwischen Editor und Terminal wechseln wollen und ein Werkzeug suchen, dessen Verhalten in einer Datei im Projekt liegt. Es passt nicht für die Produktion, und das README sagt das selbst: air hat mit Hot Deploy nichts zu tun.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 20 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 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Wofür air im Go-Projekt sitzt und wo die Grenze zur Produktion liegt
air ist ein Kommandozeilenwerkzeug für das Live-Reload von Go-Anwendungen während der Entwicklung. Man ruft air im Wurzelverzeichnis des Projekts auf, es beobachtet Dateiänderungen, baut neu und startet die Anwendung neu. Das Repository air-verse/air ist in Go geschrieben, steht unter GPL-3.0 und liegt bei 23930 Sternen, 925 Forks und 6 offenen Issues. Der letzte im Material verzeichnete Release ist v1.67.4 vom 1. August 2026.
Die Abgrenzung steht im ersten Absatz der README und ist eindeutig: air hat mit Hot Deploy in der Produktion nichts zu tun. Wer ein Werkzeug für den laufenden Betrieb sucht, ist hier falsch. Als Funktionen listet die README farbige Protokollausgabe, anpassbare Build- und sonstige Befehle, das Ausschließen von Unterverzeichnissen, das nachträgliche Beobachten neu entstandener Verzeichnisse, einen verbesserten Build-Ablauf und das konfigurierbare Laden von .env-Dateien.
Acht Installationswege von go install bis cosmtrek/air
Empfohlen wird go install github.com/air-verse/air@latest, wofür die README Go 1.25 oder neuer verlangt. Danach muss das Go-bin-Verzeichnis im Pfad liegen, etwa über export PATH="$PATH:$(go env GOPATH)/bin". Für eine projektbezogene Installation gibt es go get -tool github.com/air-verse/air@latest mit anschließendem Aufruf go tool air -v.
Weitere dokumentierte Wege sind das Skript install.sh über curl, der Dienst goblin.run, Homebrew mit brew install go-air, Scoop mit scoop install air, mise mit mise use -g air sowie ein Container-Image, das als cosmtrek/air auf Docker Hub liegt. Die README bewertet diese Wege nicht gegeneinander, sie empfiehlt lediglich go install. Bei der Frage command not found: air verweist sie auf den fehlenden Pfadeintrag, was den häufigsten Fehlerfall nach der Installation trifft.
air init, .air.toml und Konfiguration über --build.cmd und --build.entrypoint
Der schnelle Einstieg besteht aus einem Aufruf von air im Projektverzeichnis. Zuerst sucht air nach .air.toml im aktuellen Verzeichnis, findet es keine, gelten die Standardwerte. Mit air init entsteht eine .air.toml mit den Standardeinstellungen, die danach automatisch gelesen wird. Für einen abweichenden Pfad dient air -c .air.toml. Alle verfügbaren Optionen sind in der Datei air_example.toml im Repository dokumentiert.
Wer keine Datei anlegen will, konfiguriert air über Argumente. Ein vollständiges Beispiel lautet air --build.cmd "go build -o bin/api cmd/run.go" --build.entrypoint "./bin/api". Listenwerte werden kommasepariert übergeben, etwa --build.exclude_dir "templates,build", oder durch Wiederholung des Arguments, wobei die Werte in der angegebenen Reihenfolge ergänzt werden: air --env_files ".env,.env.local" --env_files ".env.secret" entspricht einer Liste aus drei Dateien. Argumente für die gebaute Anwendung stehen hinter air, getrennt durch --, also air -- -h oder air -c .air.toml -- -h. Mit air -d werden alle Protokolle ausgegeben.
build.bin ist veraltet: was build.entrypoint als String und als Array leistet
Die Repository-Beschreibung weist darauf hin, dass das Feld build.bin veraltet ist und in einer künftigen Version entfernt wird, weshalb die Einstiegspunkt-Form zu bevorzugen ist. build.entrypoint zeigt auf das Ergebnis von build.cmd und beschreibt, wie es ausgeführt wird.
Der Wert ist entweder eine Zeichenkette mit der ausführbaren Datei oder ein Array. Beim Array ist das erste Element die ausführbare Datei, aufgelöst relativ zu root, und nur wenn der Pfad kein Trennzeichen enthält, wird über die Umgebungsvariable PATH gesucht. Diese Unterscheidung ist bei Projekten mit mehreren Binaries relevant, weil sich so auch Aufrufe abbilden lassen, die zusätzliche feste Argumente brauchen. Wer noch build.bin nutzt, sollte die Umstellung einplanen, bevor das Feld entfällt.
[[build.rules]] für templ und Frontend-Assets statt Neubau
Über Neubau und Neustart hinaus kennt air zwei Mechaniken. Die erste sind Watch-Regeln, die als [[build.rules]]-Blöcke in der Konfiguration stehen. Statt neu zu bauen, führen sie bei bestimmten Dateiänderungen einen Befehl aus. Die README nennt als Anwendungsfall Frontend-Assets und Code-Generatoren wie templ.
Eine Regel braucht mindestens einen include-Matcher, zusätzlich werden exclude_regex und eine Entprellungsverzögerung unterstützt. Damit lässt sich etwa festhalten, dass eine Änderung an einer Templatedatei die Generierung anstößt, ohne dass der gesamte Go-Build läuft. Für Projekte mit gemischten Assets ist das der Teil der Konfiguration, der am ehesten über die Nützlichkeit von air im Alltag bestimmt.
Proxy-Modus mit proxy_port und app_port und die Bedingung mit dem body-Tag
Die zweite Mechanik ist der Proxy. Dabei stellt sich air vor die eigene Webanwendung: Der Browser wird auf proxy_port geöffnet, air leitet die Anfragen an app_port weiter und fügt nach einem erfolgreichen Neubau ein Skript ein, das die Seite neu lädt.
Zwei Bedingungen sind zu beachten. Die Einbettung funktioniert nur, wenn das ausgelieferte HTML ein schließendes body-Element enthält, und statische Dateien lösen das Neuladen nur aus, wenn sie von Watch-Regeln erfasst werden. Wer eine Anwendung mit eigenem Asset-Handling betreibt, sollte also prüfen, ob die Antwort überhaupt durch den Proxy läuft und ob das HTML die erwartete Struktur hat. Sonst bleibt der Neubau unbemerkt, und der Browser zeigt weiter den alten Stand.
Grenzen von air und der Unterschied zu fresh, dem Werkzeug, aus dem air entstand
Die schärfste Grenze ist im README selbst gesetzt: Kein Hot Deploy für die Produktion, und die README enthält keine Angaben zu Leistung oder Sicherheit. Hinzu kommt die GPL-3.0, die für ein reines Entwicklungswerkzeug im Alltag folgenlos bleibt, bei Weitergabe angepasster Varianten aber die Offenlegung unter derselben Lizenz verlangt. Für die Mitarbeit am Projekt braucht es Go 1.25 oder neuer, make ci installiert Abhängigkeiten und make install das Binary.
Zur Einordnung hilft der Motivationsabschnitt der README: Der Autor vermisste beim Entwickeln von Go-Webanwendungen mit gin ein Live-Reload-Werkzeug, probierte fresh, empfand es als nicht flexibel genug und schrieb die Idee als air neu. Worin der Unterschied im Einzelnen liegt, beziffert die README nicht, aber die Ausstattung von air benennt, was der Autor vermisste: eine Konfigurationsdatei .air.toml im Projekt, eigene Watch-Regeln über [[build.rules]], der Proxy für das Neuladen im Browser, das Ausschließen von Verzeichnissen und die Steuerung über Argumente wie --build.cmd und --build.entrypoint. Wer ein bestehendes Setup mit fresh betreibt, findet hier die Punkte, an denen air weiter geht, und sollte die Umstellung an einem Projekt mit mehreren Binaries prüfen.
Redaktionelles Fazit
air passt zu Go-Entwicklern, die während der Arbeit nicht ständig zwischen Editor und Terminal wechseln wollen und ein Werkzeug suchen, dessen Verhalten in einer Datei im Projekt liegt. Es passt nicht für die Produktion, und das README sagt das selbst: air hat mit Hot Deploy nichts zu tun. Vor der Umstellung klären: Ist Go 1.25 oder neuer vorhanden, wird build.bin noch verwendet, und braucht das Projekt Watch-Regeln für generierte Assets. Wer nur gelegentlich neu baut, kommt mit einem Makefile aus, wer templ oder Frontend-Artefakte im Spiel hat, profitiert von [[build.rules]] und dem Proxy.
Community-Notizen