Rails deployen, ohne ein Dockerfile zu schreiben

Die Annahme hinter den meisten “Rails containerisieren”-Anleitungen ist, dass du zuerst ein Dockerfile schreiben musst. Meistens stimmt das nicht – die Build-Methode muss nur dann zu deinem Problem werden, wenn die Standardeinstellungen deine App wirklich nicht durchschauen können, was seltener vorkommt, als es sich anhört.

Was tatsächlich die Build-Methode wählt

Methode	Wann sie läuft
Dockerfile	wenn das Repo eines hat, das die App tatsächlich baut – ein nur für die Entwicklung gedachtes Dockerfile, das einen Bind-Mount erwartet, wird automatisch übersprungen, nicht blind ausgeführt
Railpack	der Standard für jedes Repo ohne Dockerfile
Nixpacks	Fallback, wenn Railpack das Repo nicht planen kann
Buildpacks	nur wenn explizit unter Settings → Build method ausgewählt

Eine frische Rails-App ohne Dockerfile baut mit Railpack, ohne dass von Hand etwas geschrieben wird. Die Reihenfolge ist wichtiger als die Namen: Railyard prüft zuerst auf ein echtes Dockerfile und greift erst dann zu den automatischen Buildern, wenn keines existiert.

Was eine Rails-App ohne Nachfragen bekommt

Das ist der Teil, der ersetzt, was ein handgeschriebenes Dockerfile sonst leisten müsste:

• RAILS_ENV, RACK_ENV, RAILS_SERVE_STATIC_FILES und RAILS_LOG_TO_STDOUT werden gesetzt, falls noch nicht geschehen.
• Assets werden mit SECRET_KEY_BASE_DUMMY=1 gebaut, sodass zur Build-Zeit kein echtes Secret nötig ist – SECRET_KEY_BASE selbst wird einmal generiert und verschlüsselt.
• pg, mysql2/trilogy und redis/sidekiq im Gemfile werden der passenden verwalteten Datenbank zugeordnet – Rails 8s zusätzliche Datenbanken (cache, queue, cable), in config/database.yml deklariert, bekommen jeweils automatisch ihre eigene Connection-URL.
• Sidekiq, Solid Queue, GoodJob, Resque oder Delayed Job – je nachdem, was tatsächlich in der Gemfile.lock steht – wird als Worker-Prozess angeboten.
• Active Storage auf der Festplatte bekommt ohne Einrichtung ein persistentes Volume; hängst du stattdessen einen Bucket an, werden die S3-Variablen genauso automatisch injiziert.
• assets:precompile läuft automatisch im Build-Schritt, Node-Toolchain inklusive – ein tailwindcss:build- oder esbuild-Schritt, der daran angehängt wird, funktioniert einfach, keine separate Dockerfile-Stage nötig.

Wann du tatsächlich eines schreiben musst

Ein Dockerfile verdient seinen Platz, wenn die App von etwas abhängt, das wirklich außerhalb von Rubys eigenem Ökosystem liegt – einem kompilierten Binary, das die automatischen Builder nicht installieren können, einem nicht standardmäßigen Laufzeitschritt, einem aus Compliance-Gründen vorgeschriebenen Basis-Image. Abgesehen davon kommt der automatische Pfad mit alten nativen Gems zurecht (nio4r, Puma 5 und früher), die unter aktuellem GCC ohne jede Dockerfile-Änderung saubercompilieren.

Der Release-Schritt führt standardmäßig bin/rails db:prepare aus, bevor jede Version Traffic bekommt – eine eigene release:-Zeile in einem Procfile überschreibt das, falls du schon eine hast. Setze einen eigenen release_command nur, wenn db:prepare wirklich nicht reicht, etwa bei einem einmaligen Datenmigrationsskript.

Vollständige Framework-Referenz: Rails, und was der Build-Schritt tatsächlich macht: Build-Methoden.