Phoenix und Elixir

Deploye Phoenix mit Postgres, ClickHouse oder Redis, Oban-Workers und Migrationen über den Release.

Datenspeicher aus mix.exs: ecto_sql/postgrex → Postgres, ecto_ch/ch → ClickHouse, redix → Redis.
Migrationen: mix ecto.migrate. Kompilierte Releases haben zur Laufzeit kein mix, daher findet Railyard den Release dort, wo das Image ihn ablegt, und führt dessen Migrator aus (bin/migrate, falls vorhanden, sonst bin/<app> eval). mix phx.server wird genauso zu bin/<app> start.
Variablen, die in config/runtime.exs gelesen werden (BASE_URL, HTTP_PORT, LISTEN_IP, DATABASE_URL, CLICKHOUSE_DATABASE_URL…), werden automatisch verdrahtet; SECRET_KEY_BASE wird generiert.
MIX_ENV=prod und PHX_SERVER=true werden gesetzt.

Background-Jobs brauchen meist keinen zweiten Prozess

Die meisten Elixir-Apps führen Jobs mit Oban aus — einer Postgres-basierten Queue, die aus demselben Supervision-Tree wie der Web-Endpunkt startet, läuft sie bereits in dem Moment, in dem web bootet, ohne einen separaten Worker zu deklarieren oder zu skalieren. Das ist trotzdem das 12-Factor-Modell: Der Job-Runner ist nur eine der Rollen, die dein einzelner OTP-Release bereits spielt, kein zweites Deployable, das mit dem ersten synchron gehalten werden muss.

Wenn du doch einen eigenen Worker-Node willst — um die Job-Verarbeitung auf einen eigenen Prozess auszulagern, damit eine langsame Queue keine Web-Requests ausbremsen kann — deklariere ihn in einem Procfile und lass deinen Release ein Flag oder eine Env-Variable lesen, um den Start des Endpunkts zu überspringen:

web: bin/my_app start
worker: bin/my_app eval "MyApp.Release.worker()"

Füge Prozesse im Workers-Tab der App hinzu oder bearbeite sie, ohne das Repo zu ändern, und skaliere beides über die CLI:

railyard scale my-app worker=2

Konfiguration und Secrets

Alles, was config/runtime.exs mit System.get_env/2 liest, ist eine einfache Variable: setze sie unter Variables, oder per railyard env:set my-app KEY=VALUE über die CLI, und derselbe kompilierte Release läuft unverändert von Staging bis Produktion — Dev/Prod-Parität statt eines eigenen Builds pro Umgebung. Verweise mit ${{redis.RAILYARD_PRIVATE_URL}} auf eine Datenbank, ein ClickHouse oder Redis, das als eigener Service auf dem Canvas läuft — wird pro Umgebung aufgelöst. Siehe Variablen und Secrets.

Deployen

Aus einem Repo: füge die Git-URL ein, oder wähle es aus der Liste, sobald GitHub verbunden ist — Railyard liest mix.exs, trägt ecto.migrate, die bereitgestellte Datenbank und SECRET_KEY_BASE ein und deployt bei jedem Push.
Über die CLI: railyard create my-app https://github.com/me/my-app --addons postgres, oder railyard git:remote && git push railyard main im Repo.
Mit einem Klick: füge den Deploy-Button zu deiner README hinzu, oder veröffentliche im Template-Katalog, damit jeder es mit bereits ausgefüllten Addons und Variablen starten kann.