Einen Go-Service deployen: der Build, der keine Runtime braucht

Ein Go-Build erzeugt eine statisch gelinkte Binary, bei der zur Laufzeit nichts mehr aufzulösen ist — keine Interpreter-Version zu pinnen, keine Gems oder Pakete, die auf dem Server abgerufen werden müssen, der die App gleich ausführt. Das ist tatsächlich etwas anderes zu bauen als die meisten Apps in interpretierten Sprachen, und es zeigt sich in weniger Stellen, an denen ein Deploy schiefgehen kann: Sobald die Binary kompiliert, läuft sie, Punkt.

Was erkannt wird

Go selbst wird anhand von go.mod erkannt — einschließlich eines Moduls, das in einem Unterordner liegt (server/go.mod neben einem frontend/-Verzeichnis), automatisch gefunden und vom richtigen Ort aus gebaut.
Ein bekannter Datenbanktreiber-Import — github.com/jackc/pgx, github.com/lib/pq, github.com/go-sql-driver/mysql, github.com/redis/go-redis — stellt die passende Datenbank bereit und fügt DATABASE_URL oder REDIS_URL ein, ohne ein Addon von Hand hinzuzufügen.
Der Build läuft standardmäßig über Railpack, oder über dein eigenes Dockerfile, falls das Repo eines hat.

railyard create my-app https://github.com/me/my-app --port 8080

oder dieselbe URL vom Dashboard, sobald GitHub verbunden ist. Die eine Anforderung, die es wert ist, klar zu sagen: die Binary muss auf $PORT lauschen, und auf allen Interfaces, nicht nur localhost.

Worker, da Go keine Framework-Konvention zum Erkennen hat

Anders als Rails oder Django hat Go keine einzige dominante Job-Queue-Bibliothek, nach der gesucht werden könnte — es gibt nichts, das automatisch als Worker angeboten werden könnte. Das ist in Ordnung, denn es ist in jedem Fall eine Zeile:

web:    ./server
worker: ./server -mode=worker

Beide Zeilen führen genau dieselbe gebaute Binary aus; main() liest ein Flag oder eine Umgebungsvariable, um zu entscheiden, welche Schleife tatsächlich läuft. Ein Build, mehrere Prozesstypen, jeder unabhängig skaliert:

railyard scale my-app worker=2

Für alles, was nach einem Zeitplan statt kontinuierlich laufen soll, führt Cron die Binary mit einem anderen Flag zur geplanten Zeit aus und behält eine Lauf-Historie — ein saubereres Modell als eine for { time.Sleep(...) }-Schleife, die in den Worker-Prozess eingebacken ist.

Konfiguration und Secrets

Alles, was mit os.Getenv gelesen wird, ist eine reine Umgebungsvariable unter Variables, oder gesetzt mit railyard env:set my-app KEY=VALUE — niemals in die Binary kompiliert, sodass genau dasselbe Build-Artefakt unverändert von Staging bis Produktion läuft. Keine Neukompilierung pro Umgebung, was genau der Punkt ist: Ein Konfigurationsunterschied zwischen Staging und Produktion sollte immer eine Variable sein, niemals ein anderer Build.

Dein eigenes Image bauen, wenn du es willst

railyard deploy my-app --local baut mit deinem eigenen Docker und pusht direkt ein einzelnes Image, statt den gemeinsamen Team-Builder zu verwenden — nützlich, wenn ein Build etwas Spezifisches für deine lokale Toolchain braucht, das der Standard-Build-Pfad nicht wissen muss.

Vollständige Referenz: Go-Docs, Worker und geplante Jobs.