Go auf Nodion deployen

Go Schritt für Schritt deployen

1. Auf PORT lauschen Nodion setzt PORT für den Web-Prozess; dein Server lauscht darauf auf allen Interfaces. r.Run() von Gin ohne Adresse nutzt PORT schon von selbst. Bei Echo, Fiber oder Chi übergibst du ":" + port selbst. main.go

   package main
   
   import (
   	"log"
   	"net/http"
   	"os"
   )
   
   func main() {
   	port := os.Getenv("PORT")
   	if port == "" {
   		port = "8080"
   	}
   	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
   		w.Write([]byte("ok"))
   	})
   	log.Fatal(http.ListenAndServe(":"+port, nil))
   }

2. Ein Binary pro cmd/-Ordner Ohne cmd/-Ordner baut Nodion den Root des Moduls zu einem Binary. Jeder cmd/<name>-Ordner mit Go-Dateien wird stattdessen ein eigenes Binary, das Root-Paket wird dann nicht gebaut. Der Web-Prozess startet das einzige Binary, sonst das mit dem Namen server, api, web oder app, sonst das erste; jedes weitere Binary wird ein Prozesstyp mit demselben Namen.

   cmd/server/main.go
   cmd/worker/main.go
   cmd/migrate/main.go

3. Build-Einstellungen prüfen Binaries entstehen mit CGO_ENABLED=0 und -ldflags "-s -w". Braucht eine Dependency cgo, etwa mattn/go-sqlite3, setz auf dem Tab Environment CGO_ENABLED=1 mit dem Häkchen Build. Eine Build-Variable GOFLAGS_LDFLAGS ersetzt die ldflags; nimm -s -w dort mit auf, wenn du sie behalten willst.
4. App anlegen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an, wähle Branch und Region EU Central. Lass die Build-Strategie auf Buildpacks; liegt ein Dockerfile im Repository, wählt das Formular stattdessen Dockerfile.
5. PostgreSQL anhängen und Migrationen ausführen Häng auf dem Tab Environment eine Datenbank aus derselben Region an; DATABASE_URL kommt beim nächsten Deploy an, und PostgreSQL-Treiber wie pgx nehmen die URL so, wie sie ist. Deine Binaries liegen zur Laufzeit im PATH, ein cmd/migrate-Binary kann also als Release-Schritt laufen, bei jedem Build einmal, bevor die neue Version startet. Procfile

   release: migrate

Gut zu wissen

• Worker ohne ProcfileEin Binary aus cmd/worker wird zum Prozesstyp worker. Leg auf dem Tab Processes einen Prozess worker ohne Port an und lass den Befehl leer; er startet dieses Binary. Nenn das Web-Binary server, api, web oder app, damit der Web-Prozess kein anderes erwischt.
• Immer das neueste GoDie go-Zeile in der go.mod und eine .go-version wählen keine ältere Toolchain: Jeder Build nutzt das neueste Go-Release, das Nodion gebaut hat. Lass deine CI ebenfalls gegen das neueste Go laufen.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Warum wir eigene Buildpacks auf Ubuntu 26.04 gebaut haben Unsere Buildpacks folgen der Cloud-Native-Buildpacks-Spezifikation, aber Stack, Language Packs und Runtime-Versionen sind unsere. Darum.
• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.

Go auf Nodion: Fragen und Antworten