Config-Variablen zur Build-Zeit
In den Build exportiert, wie es die meisten Plattformen tun, damit ein Asset-Precompile, das die App startet, ihre Datenbank-URL findet.
Deploy-Methoden
Sieben Wege zu bauen und zu deployen.
Railyard wählt den Build-Pfad, den dein Repo braucht. Alles, was nach dem Build kommt, vom Release bis zum Rollback, funktioniert für alle gleich.
| Methode | Quelle | Was läuft | Status |
|---|---|---|---|
| image:// | Ein Registry-Tag | Pull und Ausführung. Kein Clone, kein Build. | deployt |
| dockerfile | Ein Repo mit Dockerfile | Clone, docker build, Ausführung. | deployt |
| railpack | Ein Repo, kein Dockerfile (Standard) | Railpack erkennt die Sprache und baut ein Image. Keine Konfiguration. | deployt |
| cnb | Ein Repo, kein Dockerfile | pack build gegen heroku/builder:24, dann Ausführung. | deployt |
| nixpacks | Ein Repo, kein Dockerfile | Nixpacks schreibt ein Dockerfile, danach läuft der Build normal weiter. | deployt |
| build server | Jede Repo-Methode | Einmal auf einem dedizierten Server bauen, danach überall in deiner Flotte ausführen. | deployt |
| Procfile | Ein Repo mit Procfile | Deklariert Web- und Worker-Prozesse plus den Release-Hook. | deployt |
Eine Pipeline
Eine Pipeline für jede Build-Methode.
Image, Dockerfile, Buildpacks, Nixpacks oder Procfile: Jeder Pfad erzeugt ein Image. Von da an läuft der Deploy gleich ab, inklusive eines schnellen Redeploys desselben Commits.
- Config-Variablen werden in den Build exportiert
- Der Release-Hook läuft, bevor der Traffic umgeleitet wird
- Readiness-Check, dann ein Wechsel ohne Downtime
$ git push railyard main
Enumerating objects: 12, done.
remote: Baue storefront (Dockerfile)
remote: #7 RUN bundle install
remote: #9 RUN bin/rails assets:precompile
remote: Release: bin/rails db:migrate
remote: Health-Check bestanden (GET /up 200)
remote: Live, der Traffic ist auf das neue Release gewechselt
a1b2c3d..e4f5a6b main -> main
Jeder Build
Die gleichen Build-Funktionen, bei jeder Methode.
Private Repos und Submodule
GitHub einmal verbinden; private Repositories und ihre Submodule klonen automatisch, begrenzt auf die verbundenen Repos.
Build-Args und Secrets
Build-Argumente und Secrets in den Build geben, ohne sie ins Image zu backen.
Persistente Volumes
Benannte Volumes an einem Pfad deiner Wahl, nie von einem Redeploy gelöscht.
Addons, fertig verdrahtet
Postgres mit pgvector, MySQL, Redis, Memcached und Objektspeicher, mit injizierten Connection-Strings.
Release-Hooks
Migrationen laufen, bevor die neue Version Traffic erhält; ein Fehler stoppt den Deploy.
Statische Sites und Functions
Ein statischer Build wird mit automatischem HTTPS ausgeliefert; Functions sind ein paar Zeilen TypeScript, bearbeitbar im Canvas.
Templates und ein Deploy-Button
Rund 200 One-Click-Templates, und ein README-Badge, das einen vorausgefüllten Deploy öffnet.
Bewährt bei kommerzieller Software: Campfire, 37signals' bezahltes Rails-8-Produkt, läuft sowohl über den Dockerfile-Pfad als auch über Buildpacks.
Deploye deine erste App auf einem Server, der dir gehört.
Verbinde eine Maschine mit Host, Benutzer und SSH-Key, oder lass Railyard eine in deinem Cloud-Konto anlegen. Railyard installiert den Rest und beobachtet, bis sie online ist.
Kostenloser Plan, keine Kreditkarte, und 14 Tage Pro für jedes neue Team. Ein fester Preis pro Team.