Notizen aus dem Aufbau einer Deployment-Plattform.
Mechanismen, die wir richtig hinbekommen mussten, Entscheidungen, die wir verteidigen mussten, und Migrationen, die wir mehr als einmal durchgeführt haben.
Elestio vs Railyard: zwei Wege, einen verwalteten Server zu kaufen, ehrlich verglichen
Elestio verkauft verwaltetes Open-Source-Hosting pro Dienst, mit kostenpflichtigen Support-Stufen obendrauf. Railyard verkauft eine Plattform zum Pauschalpreis pro Team. Das unterscheidet sich wirklich, und das nicht.
Coolify vs. Dokploy vs. Railyard: drei Wege, eine selbst gehostete PaaS zu betreiben, ehrlich verglichen
Coolify und Dokploy sind kostenlose Open-Source-Panels, die Sie selbst installieren und betreiben. Railyard ist eine gehostete Kontrollebene für Server, die weiterhin Ihnen gehören. So viel kostet dieser Unterschied wirklich, an Zeit und an Geld.
Railway und Heroku wurden beide über geteilte Infrastruktur gehackt. Das eigentliche Muster, kein Verkaufsgespräch.
Railways Umgebungsvariablen-Breach vom Oktober 2026 und Herokus OAuth-Token-Breach vom April 2022 führen beide auf dieselbe Art von Sache zurück: einen Riss in geteilter Plattform-Infrastruktur, der viele Kunden gleichzeitig trifft. Was dieses Muster tatsächlich bedeutet, ehrlich betrachtet.
Heroku ist jetzt im Sustaining-Engineering-Modus, und das ist eine andere Art von Risiko als eine Preiserhöhung
Heroku ging im Feb. 2026 in den Sustaining-Engineering-Modus: keine neuen Features, keine neuen Enterprise-Deals. Was dieses Risiko bedeutet, wenn du noch in Produktion dort läufst.
Fly.ios Incident-Muster im September und Oktober 2026, verifiziert gegen die eigene Statusseite
Kein einzelner dramatischer Ausfall — ein echtes Muster von 25 Incidents auf Fly.ios eigener Status-Historie in sieben Wochen. Was ein geteiltes Multi-Tenant-Edge-Netzwerk dich kostet, Incident für Incident verifiziert.
Renders Preisänderung im April 2026: keine Pro-Seat-Gebühr mehr, aber deutlich weniger Bandbreite inklusive
Render hat die inkludierte Bandbreite in seiner Preisänderung von April 2026 um bis zu das 20-Fache gekürzt. Was sich geändert hat, Rechnungsbeispiele vorher/nachher, und was ein pauschaler Teampreis vermeidet.
Vercels Deployment-Ausfall im Oktober 2026: was Vercels eigene Statusseite zeigt
Vercels Statusseite verzeichnete am 12. Oktober 2026 einen 6,5-stündigen Vorfall mit 'erhöhten Build- und Deployment-Fehlern'. Hier steht, was dort steht, und was dich eine gemeinsame Build-Pipeline kostet.
Hatchbox hat den Preis von 10 $ auf 15 $ pro Server erhöht, und das ist ein gesundes Zeichen für ein kleines Team
Hatchbox' Preis stieg im Sept. 2026 von 10 $ auf 15 $ pro Server. Was sich geändert hat, warum es fair ist, und wie sich Pro-Server-Abrechnung von flacher Pro-Team-Preisgestaltung unterscheidet.
Railways Environment-Variable-Breach: was Railway bestätigt hat, und was sich auf einem eigenen Server ändert
Railway gab bekannt, dass Kunden-Environment-Variablen im Oktober 2026 offengelegt wurden, und pausierte alle Deployments. Hier ist, was Railway selbst bestätigt hat, was noch aus zweiter Hand kommt, und was ein BYO-Server-Modell tatsächlich ändert.
Eine App plus Postgres: was es tatsächlich kostet, Plattform für Plattform
Die veröffentlichten Preise für den Betrieb einer kleinen App mit Datenbank, direkt verglichen — einschließlich dessen, was du tatsächlich mietest, gegenüber dem, was du mietest plus Aufschlag.
Einen KI-Agenten deine App deployen lassen, sicher
Ein scoped MCP-Server für Claude Code, Cursor und jeden anderen MCP-Client: was er allein tun kann, was nicht, und warum destruktive Aktionen auf einen Menschen warten.
Automatisches Postgres-Failover, selbst gehostet
Wie eine Live-Standby-Beförderung von Postgres auf deinen eigenen Servern wirklich aussieht: das 3-Minuten-Erkennungsfenster, was kopiert wird, was nicht, und wie sich das mit einer Managed-Datenbank vergleicht.
Selbst gehostetes Plausible-Analytics, in einem Befehl
Wir hatten keine Ahnung, wer railyard.run eigentlich las. Hier ist der Ein-Klick-Plausible-Stack, den wir auf unserer eigenen Plattform gestartet haben, um das zu klären, und was es wirklich gebraucht hat.
Was passiert, wenn deine KI-gebaute App in Produktion geht
Ein Agent kann an einem Nachmittag eine funktionierende App schreiben. Er weiß nicht, dass deine Secrets nicht im Klartext liegen sollten, oder dass ein Deploy-Token nicht löschen können sollte. Die Plattform darunter muss das stattdessen wissen.
Eine Next.js-App deployen, ohne einen Vercel-Account
Next.js erkennt sich selbst und baut sich auf Railyard genauso wie überall sonst — der Unterschied ist, dass der Server darunter dir gehört und nicht nach einzelnen Requests abgerechnet wird.
Canary-Deploys, die tatsächlich die Fehlerrate beobachten, nicht nur einen Timer
Schick einem neuen Release 5% des Traffics, beobachte es gegen den Rest der App, und lass es sich selbst zurückrollen, wenn die 5xx-Rate steigt – auf Servern, die dir gehören, nicht am Canary-Schalter einer verwalteten Plattform.
Die Timeline der selbst gehosteten PaaS, und wo die Idee eigentlich herkommt
Cloud 66 hat 2012 bewiesen, dass man 'die App des Kunden niemals selbst hosten' muss. Hier ist die echte Linie von Heroku über Fly, Render, Railway bis Coolify – und warum die Idee immer wieder neu gebaut wird, statt sich auf einen Gewinner einzupendeln.
Eine Status-Page, die kein 29-$-pro-Monat-Abo ist
90-Tage-Uptime-Balken, Incidents, die sich selbst öffnen und schließen, ein JSON-Feed für dein eigenes Tooling — gebaut aus denselben Uptime-Checks, die die Plattform schon ausführt, kein separates Produkt zum Bezahlen.
Phoenix deployen, wenn die Job-Queue schon im Release steckt
Oban läuft im selben OTP-Supervision-Tree wie der Web-Endpoint — kein zweiter Worker-Prozess zu deklarieren, nur um Hintergrundjobs laufen zu lassen.
Eine WAF und Rate Limiting ohne separaten Edge-Anbieter
OWASP-Core-Rule-Set-Filterung, Rate-Limits pro Pfad, Länderblocking — konfiguriert an der App, durchgesetzt bevor der Request sie erreicht. Hier ist genau, was heute live ist und was noch ausrollt.
Laravel deployen, ohne eine Queue-Worker-Config von Hand zu schreiben
APP_KEY, Migrationen, Horizon, Reverb, Octane — Railyard liest, was bereits in composer.json und .env.example steht, statt dich zu bitten, es doppelt zu deklarieren.
Eine stabile ausgehende IP, ohne NAT-Gateway-Rechnung
Die Adresse deines Servers auf die Allowlist einer Drittanbieter-API zu setzen, bedeutet auf einer Multi-Tenant-Plattform meist, ein NAT-Gateway aufzusetzen. Auf einem Server, den du selbst besitzt, war die IP nie geteilt.
Einen Go-Service deployen: der Build, der keine Runtime braucht
Eine Go-Binary braucht keinen abgerufenen Interpreter, keine aufgelöste Runtime-Version und nichts, was zur Deployzeit installiert werden muss — was sie zu einer der einfachsten Dinge macht, die man auf einem gemeinsamen Build-Server korrekt baut.
Django deployen, ohne von Hand ein Procfile zu schreiben
collectstatic, gunicorn, Migrationen, Celery – Railyard erkennt, was schon in requirements.txt steht, statt dich zu bitten, dieselbe Information doppelt anzugeben.
Deine eigene ChatGPT-ähnliche Oberfläche selbst betreiben
LibreChat verbindet sich mit welchen Model-Providern auch immer du ihm Keys gibst, mit deinen Unterhaltungen in einer Datenbank, die du kontrollierst. Zwei echte Fallstricke, auf die wir bei der Verifizierung gestoßen sind, und wie das Template sie für dich vermeidet.
Spring Boot deployen: warum ein Dockerfile die richtige Antwort ist, kein Workaround
Build- und Run-Befehle der JVM variieren je nach Projektaufbau zu stark, um sicher zu raten — genau deshalb ist ein Dockerfile der bewusste, korrekte Weg, eine Spring-Boot-App zu deployen, kein Workaround für fehlende Unterstützung.
Flask deployen: Ein Micro-Framework braucht Micro-Konfiguration, nicht gar keine
Flask nimmt kein Migrationstool oder eine Job-Queue an, so wie Django das tut — was bedeutet, dass ein Flask-Deploy ehrlich darüber ist, was tatsächlich da ist, statt eine Konvention zu erraten, die nicht existiert.
Deine eigene Mastodon-Instanz betreiben, Ende-zu-Ende verifiziert
Direkt aus Mastodons eigenem Dockerfile gebaut, Postgres und Redis automatisch verdrahtet, Verschlüsselungs-Secrets gleich beim ersten Mal korrekt generiert — kein vereinfachter Fork des echten Dings.
Laravel auf deinem eigenen DigitalOcean-Droplet, ohne Forge
Forge konfiguriert dir einen DigitalOcean-Droplet, gegen eine monatliche Gebühr, zusätzlich zu den Kosten des Droplets selbst. Hier ist, was auf diesem Droplet tatsächlich passieren muss – und wie du es ohne die zusätzliche Rechnung bekommst.
Ein Deploy-Button für dein README, der auf Server zeigt, die Leuten gehören
Das One-Click-Deploy-Badge-Muster, aber landend auf dem eigenen DigitalOcean- oder Hetzner-Account des Besuchers statt auf der nutzungsabhängigen Abrechnung einer Managed-Plattform.
Eine Service-Referenz, die nie bricht — selbst bevor du Private Networking aktivierst
<name>.railyard.internal löst je nachdem, wo die beiden Apps tatsächlich laufen, unterschiedlich auf — gleiches Container-Netzwerk, öffentliches HTTPS oder ein cloudübergreifendes WireGuard-Mesh — ohne dass die App je weiß, welcher Fall zutrifft.
Warum ein Deploy wirklich fehlschlägt, Ursache für Ursache
Ein Build-Timeout ist nicht dasselbe Problem wie eine App, die auf 127.0.0.1 statt auf 0.0.0.0 antwortet – die echten Ursachen hinter einem fehlgeschlagenen Deploy, und die konkrete Lösung für jede.
railyard.yml: die Konfiguration deiner App als eine Datei in git
Die aktuelle Konfiguration einer App als Datei ziehen, offline validieren, zurück anwenden — exakt das, was die drei Kommandos heute tun, und was sie noch nicht tun.
Eine Preview-Umgebung pro Pull Request, auf Servern, die dir gehören
Jeder PR bekommt seine eigene laufende Kopie, die beim Schließen automatisch abgebaut wird — und anders als die meisten Preview-Systeme schläft sie, wenn niemand hinschaut, statt 24/7 abzurechnen.
Spring Boot auf Hetzner deployen
Eine Spring-Boot-App als mehrschichtiges Docker-Image packen, Postgres und Caddy-HTTPS hinzufügen und auf einem Hetzner-Server mit Backups und einem Release-Schritt betreiben.
Cloud-Verschwendung finden, nach der niemand sucht
Nicht angehängte Disks, untätige Load Balancer, Server, die bei 4% CPU laufen – ein Scan deiner echten Cloud-Accounts, mit einem Ein-Klick-Fix für das meiste, was er findet, nicht nur ein Dashboard, das dir sagt, selbst nachzuschauen.
SvelteKit auf Hetzner deployen
Eine SvelteKit-App mit adapter-node bauen, containerisieren und hinter Caddy mit HTTPS auf einem Hetzner-Cloud-Server servieren, den du selbst kontrollierst.
Wenn ein Secret eine Datei sein muss, keine Umgebungsvariable
Ein GCP-Service-Account-JSON oder ein Client-Zertifikat passt nicht in ein KEY=VALUE-Paar. Die meisten PaaS-Umgebungsvariablen-Bildschirme haben darauf keine gute Antwort — hier ist die, die es hat.
MediaCMS für Video-Hosting selbst hosten
Betreibe MediaCMS mit Postgres, Redis und einem separaten Celery-Worker für Transcoding in Docker Compose, hinter Caddy HTTPS, mit Backups.
SSO und ein Audit-Log, ohne Enterprise-Vertriebsgespräch
Single Sign-On, SCIM-Provisioning und ein echtes Audit-Log sind keine Features, für die ein 6-köpfiges Team erst einen Vertrag aushandeln muss.
Wie man einen Telegram-Bot hostet, der immer online ist
Ein echter python-telegram-bot-Bot, der Tradeoff zwischen Long-Polling und Webhook ehrlich erklärt, ein Dockerfile, Restart-Policy, und der Deploy-Weg.
Nuxt auf Hetzner deployen
Baue eine Nuxt-App mit ihrem Nitro-node-server-Output, containerisiere sie und liefere sie hinter Caddy mit HTTPS auf einem Hetzner-Cloud-Server aus.
Warum eine eigene Domain erst dann geroutet wird, wenn du bewiesen hast, dass sie dir gehört
Subdomain-Takeover ist eine echte, gut dokumentierte Schwachstellenklasse – ein DNS-Eintrag, der auf Infrastruktur zeigt, die man nicht wirklich kontrolliert. Hier ist der konkrete Check, der das standardmäßig verhindert.
10 SaaS-Abos, die du durch selbst gehostete Apps mit einem Klick ersetzen kannst
Echte Open-Source-Projekte, in derselben Kategorie wie das SaaS-Tool daneben, jedes mit einem Klick aus Railyards Template-Katalog startbar – kein Feature-für-Feature-Versprechen, sondern eine App, die du wirklich ausprobieren kannst.
Castopod selbst hosten, um einen Podcast zu veröffentlichen
Betreibe Castopod mit MariaDB und Redis in Docker Compose hinter Caddy HTTPS, veröffentliche einen RSS-Feed, der dir selbst gehört, und sichere das Audio-Volume.
TablePlus oder psql mit einer Datenbank ohne öffentlichen Port verbinden
Managed-Datenbanken sind standardmäßig privat – nur Apps auf dem Server erreichen sie. So verbindest du trotzdem einen GUI-Client auf deinem Laptop, ohne die Datenbank ins Internet zu öffnen.
Eine Rails-App von Heroku wegziehen
Ein praktischer Migrationspfad von einer verwalteten Plattform zu eigenen Servern: zuerst Buildpacks, dann ein Dockerfile, Addons und die Release-Phase.
Einen Mastodon-Server selbst hosten
Betreibe eine echte Mastodon-Instanz mit Postgres, Redis, der Streaming-API und Sidekiq als eigenständige Dienste, hinter Caddy HTTPS, mit Backups.
Eine Express-App auf DigitalOcean deployen
Betreibe eine Express-5-App mit einer Postgres-gestützten Route auf einem DigitalOcean-Droplet, hinter Caddy für HTTPS, plus die Abkürzung, die das Setup überspringt.
Per Slack benachrichtigt werden, bevor ein Kunde es merkt, nicht danach
Deploy-Fehler, Crash-Loops, eine volllaufende Festplatte, ein bald ablaufendes Zertifikat – eine Regel-Engine, drei Kanäle, pro App oder fürs ganze Team.
LibreChat für deine eigene ChatGPT-artige App selbst hosten
Betreibe LibreChat mit MongoDB in Docker Compose hinter Caddy HTTPS, mit echten generierten Secrets, geschlossener Registrierung und eingerichteten Backups.
Eine Go-Web-App auf Hetzner deployen
Baue und liefere einen Go-net/http-Service mit Postgres auf einem Hetzner-Server mit Docker, Compose und Caddy, mit Backups und einem wiederholbaren Upgrade-Pfad.
Workflow-Automatisierung ohne die Pro-Ausführung-Rechnung
n8n macht, was Zapier und Make machen — APIs verbinden, ohne Glue-Code zu schreiben — nur dass dir der Server gehört und niemand zählt, wie oft ein Workflow diesen Monat gelaufen ist.
AFFiNE selbst hosten, eine Open-Source-Notion-Alternative
Betreibe AFFiNE, die Open-Source-Alternative zu Notion und Miro, mit Postgres und Redis in Docker Compose, Caddy-HTTPS, Backups und einem Upgrade-Pfad.
Ein Deploy ist nicht fertig, wenn der Container startet
Ob ein Container bereit ist und deine App wirklich erreichbar ist, sind zwei verschiedene Dinge. Railyard prüft beides und macht ein Rollback, wenn die neue Version nie live geht.
Eine Django-App von Heroku zu DigitalOcean verschieben
Migriere eine Django-Produktions-App von Heroku weg auf einen DigitalOcean-Droplet: dockerisieren, die Postgres-Daten rüberziehen, Config Vars mappen und DNS umschalten.
Meilisearch für schnelle Suche selbst hosten
Betreibe Meilisearch in Docker Compose hinter Caddy HTTPS, mit einem echten Master-Key, einem Backup-Snapshot und einem wiederholbaren Upgrade-Pfad.
Sidekiq- oder Celery-Worker neben deiner Web-App betreiben
Richte einen dedizierten Sidekiq- oder Celery-Worker-Prozess neben deiner Web-App ein, mit Docker Compose, systemd und echten Fehlerfällen abgedeckt.
Wo Railyard tatsächlich gegen Heroku, Railway, Render und Fly gewinnt – und wo nicht
Ein ehrlicher Blick auf die reale Vergleichsmatrix: vier Dinge, die direkt daraus folgen, den Server selbst zu besitzen, und drei Dinge, bei denen ein Konkurrent gleichauf oder voraus ist.
Wie du einen Cron-Job ohne eigenen Server betreibst
Du hast ein Skript, keine App, und brauchst es nach einem Zeitplan. Zuerst die manuelle Version (eine billige VM, Crontab, Monitoring, dass es wirklich lief), dann Railyards eigentlicher Cron-Mechanismus, akkurat benannt.
Phoenix auf Hetzner deployen
Baue ein Phoenix-Release und betreibe es in Produktion auf einem Hetzner-Cloud-Server, mit Postgres und Caddy für HTTPS, alles in Docker mit mix release.
Datenbank-Addon oder Datenbankserver: der Unterschied, der wirklich zählt
Beide geben dir Postgres. Nur einer überlebt den Verlust der Maschine, auf der er läuft. Hier ist genau, wo die Grenze liegt – und wann du wechseln solltest.
Heroku Postgres migrieren, ohne Maintenance-Window
Die Datenbank ist der Teil einer Heroku-Migration, über den sich Teams tatsächlich Sorgen machen. Hier ist genau, wie die Daten umziehen, und warum es kein echtes Downtime-Fenster zu planen gibt.
changedetection.io selbst hosten, um Webseiten zu beobachten
Betreibe changedetection.io auf einem 6-€/Monat-Server, um benachrichtigt zu werden, wenn sich eine Webseite ändert: Preissenkungen, Wiederverfügbarkeit oder eine aktualisierte Hinweisseite.
Eine Rails-App Schritt für Schritt von Heroku nach Hetzner umziehen
Migriere eine Produktions-Rails-App von Heroku nach Hetzner: dockerisieren, die Postgres-Daten umziehen, Config-Vars abbilden und DNS sicher umschalten.
Flask auf DigitalOcean deployen
Betreibe eine Flask-App in Produktion auf einem DigitalOcean-Droplet: gunicorn, Postgres und Flask-Migrate hinter Caddy für HTTPS, alles in Docker.
Healthchecks.io selbst hosten, um Cron-Jobs zu überwachen
Betreibe Healthchecks.io auf deinem eigenen Server mit Docker, Postgres und HTTPS: das komplette Compose-Setup, SMTP-Alerts, Backups und der Ein-Klick-Shortcut.
Wie man Docker deployt, ohne einen Server zu verwalten
Du hast schon ein Dockerfile. Was 'einen Server verwalten' tatsächlich bedeutet (OS-Updates, der Reverse-Proxy, TLS-Erneuerung, Monitoring), kurz die manuelle Version, dann der Weg, der sich darum kümmert.
Heroku Review Apps durch Pull-Request-Previews ersetzen
Baue eigene Preview-Umgebungen pro PR mit GitHub Actions und Docker, und sieh dir dann an, wie eine gehostete Version mit Sleep-on-Idle aussieht.
Memos für Notizen selbst hosten
Betreibe Memos, eine schlanke selbst gehostete Notiz-App, auf deinem eigenen 6-Dollar-Droplet mit HTTPS, Backups und einem Upgrade-Pfad.
Cron-Jobs für dockerisierte Apps ausführen
Füge einer containerisierten App geplante Jobs hinzu – mit einem dedizierten Scheduler-Container und Docker-Labels, ohne cron-Daemon im Image.
FastAPI auf Hetzner deployen
Betreibe eine FastAPI-App in Produktion auf einem Hetzner-Cloud-Server: Postgres, Alembic-Migrationen und Caddy für HTTPS, alles in Docker.
Eine Cloud-66-Alternative, die sich nicht in den Weg stellt
Cloud 66 hat das Bring-your-own-Server-Modell vor Jahren bewiesen. Hier ist die leichtere, günstigere Variante derselben Idee, und was ein Umzug konkret bedeutet.
Rocket.Chat für Team-Chat selbst hosten
Betreibe Rocket.Chat auf deinem eigenen Hetzner-Server mit einem MongoDB-Replica-Set, HTTPS, Backups und einem Upgrade-Pfad, von Anfang bis Ende.
Wie man ein Node.js-Backend mit Postgres deployt
Express und pg, echte Migrationen, Connection-Pooling, das Postgres nicht erschöpft, Docker Compose für die lokale Entwicklung, dann der Deploy-Weg, der die Datenbank für dich provisioniert.
Eine Next.js-App von Vercel auf deinen eigenen Server umziehen
Hol eine Next.js-App von Vercel auf einen Server, den du selbst besitzt: Umgebungsvariablen, ein Standalone-Docker-Build, HTTPS, Cron-Jobs und ein sicheres DNS-Cutover.
Laravel auf Hetzner deployen
Betreibe Laravel in Produktion auf einem Hetzner-Cloud-Server mit FrankenPHP, MySQL, einem Queue-Worker und dem Scheduler in Docker, mit automatisch eingerichtetem HTTPS.
Was beim Umzug von Render tatsächlich kaputtgeht
Renders Developer Experience ist wirklich gut. Hier ist, was den Umzug auf einen eigenen Server überlebt, und die Handvoll Dinge, die nicht automatisch mitkommen.
Metabase mit Postgres selbst hosten
Betreibe Metabase, das Open-Source-BI-Tool, auf deinem eigenen Server mit Docker, einer eigenen Postgres-Metadatenbank und HTTPS über Caddy, ohne Lizenz pro Sitzplatz.
Heroku Scheduler durch Cron-Jobs auf deinem Server ersetzen
Herokus Scheduler-Jobs laufen nicht garantiert pünktlich oder überhaupt. So ersetzt du sie durch Cron auf deinem eigenen Server, mit Locking und echten Logs.
Jitsi Meet für Videoanrufe selbst hosten
Betreibe Jitsi Meet, die Open-Source-Videokonferenzplattform, auf deinem eigenen Docker-Server mit HTTPS, und den einen Port, über den die meisten Setups stolpern.
HTTPS für viele Apps auf einem Server
Mehrere kleine Apps auf einer VPS hinter einer einzigen Caddy-Instanz betreiben, jede auf ihrer eigenen Subdomain mit automatischem Zertifikat, plus die automatisierte Version.
Next.js auf DigitalOcean deployen
Betreibe eine produktive Next.js-App auf einem DigitalOcean-Droplet: ein standalone Docker-Build, Caddy für automatisches HTTPS und ein wiederholbarer Weg, um Updates auszuliefern.
Immich für deine Fotobibliothek selbst hosten
Betreibe Immich, die Open-Source-Alternative zu Google Photos, auf deinem eigenen Server mit Docker, Postgres und HTTPS über Caddy, und richte dein Handy darauf ein.
Wie man einen Discord-Bot 24/7 hostet
Ein echter discord.js-Bot in einem Dockerfile, warum er einen always-on Prozess statt eine serverless Function braucht, Restart-Policy, Logging und der One-Click-Deploy-Weg.
Die zwölf Faktoren, auf einem Server, den du besitzt
Herokus 1.0-Team schrieb das Twelve-Factor-Manifest, um zu beschreiben, was ihre Plattform von einer App verlangte. Hier sind dieselben zwölf Faktoren, abgebildet darauf, wie sie auf Infrastruktur, die du besitzt statt mietest, tatsächlich greifen.
Weg vom Heroku Key-Value Store (Redis)
Heroku hat sein Redis-Add-on in Key-Value Store umbenannt. So betreibst du statt dessen dein eigenes Redis, ziehst die Daten um und hältst deine App am Laufen.
Next.js auf Hetzner deployen
Baue eine Next.js-App im Standalone-Output-Modus, containerisiere sie und liefere sie hinter Caddy mit HTTPS auf einem Hetzner-Cloud-Server aus.
Gitea für deinen eigenen Git-Server selbst hosten
Betreibe Gitea auf deinem eigenen Server mit Docker Compose, HTTPS über Caddy und Git über SSH, plus ein Backup, das du durch Wiederherstellen getestet hast.
Von Fly.io zu deinem eigenen Server umziehen
Exportiere das Image, die Secrets und die Postgres-Daten deiner App von Fly und betreibe sie auf einem Server, den du selbst besitzt, mit Docker Compose und Caddy.
Umami Analytics selbst hosten
Betreibe Umami auf deinem eigenen Server mit Docker Compose, Postgres und automatischem HTTPS über Caddy, mit Backups, die du mindestens einmal wiederhergestellt hast.
Automatische Postgres-Backups, die du wirklich wiederherstellen kannst
Skripte pg_dump, planst es mit cron, schickst es vom Server weg, bereinigst alte Kopien und beweist, dass jedes Backup saubereinwandfrei wiederherstellbar ist, bevor du es brauchst.
Django mit Celery auf Hetzner deployen
Betreibe Django, gunicorn, Celery und Postgres auf einem Hetzner-Server mit Docker Compose, Caddy und HTTPS, von null bis Produktion.
Vaultwarden selbst hosten, den Bitwarden-kompatiblen Passwort-Manager
Betreibe deinen eigenen Bitwarden-kompatiblen Tresor mit Vaultwarden, Docker Compose und Caddy, mit gehashtem Admin-Token und funktionierendem Backup.
Rails-Autoscaling nach CPU und Antwortzeit, nicht nach Bauchgefühl
Setze eine Unter- und eine Obergrenze und lass die echte Last entscheiden – plus wie du Replicas vor einem Traffic-Spike, den du tatsächlich vorhersehen kannst, vorwärmst.
Von Railway auf deinen eigenen Server umziehen
Exportiere deine Railway-App und ihre Postgres-Datenbank, stelle sie auf deinem eigenen VPS hinter Caddy auf, und der One-Click-Import, der das meiste davon für dich erledigt.
Django auf DigitalOcean deployen
Betreibe eine Django-App auf einem DigitalOcean-Droplet mit Postgres, gunicorn und Caddy für HTTPS, plus dem One-Click-Weg, der das Setup überspringt.
Cron-Jobs und Background-Worker ohne separaten Dyno
Ein geplanter Befehl und ein Background-Worker sind beide einfach Prozesse deiner bestehenden App, nicht eine zweite Sache, die du separat deployen, skalieren oder bezahlen musst.
Ghost mit MySQL selbst hosten
Betreibe Ghost auf deinem eigenen Server mit MySQL, Docker Compose und Caddy, inklusive echter Backups, HTTPS und einem getesteten Upgrade-Pfad.
Von Render auf deinen eigenen Server umziehen
Eine vollständige Anleitung, um einen Render-Webservice und seine Postgres-Datenbank auf einen eigenen Server zu übertragen, am Ende mit HTTPS und eingerichteten Backups.
Uptime Kuma selbst hosten für Statusseiten und Alerts
Betreibe Uptime Kuma auf deinem eigenen Server mit Docker Compose und Caddy-HTTPS, füge Backups und Upgrades hinzu, und sieh auch den Ein-Klick-Weg.
Einen neuen Ubuntu-Server absichern, bevor du Apps darauf betreibst
Sichere einen frischen Ubuntu-24.04-Server vor dem Deployment: ein Sudo-User, SSH nur per Key, ufw, fail2ban und automatische Sicherheitsupdates, Schritt für Schritt.
Eine Rails-App auf DigitalOcean deployen
Eine vollständige Anleitung: eine dockerisierte Rails-App mit Postgres und HTTPS auf einem 12-$/Monat-DigitalOcean-Droplet deployen, mit Backups und Upgrades.
Chatwoot mit Postgres, Redis und Sidekiq selbst hosten
Betreibe deinen eigenen Chatwoot-Support-Posteingang auf einem VPS, den du kontrollierst, mit Postgres, Redis, einem Sidekiq-Worker und HTTPS, von einem leeren Server bis zum funktionierenden Login.
OpenTelemetry-Tracing, ohne deine Infrastruktur anzufassen
Zeig deine App auf einen beliebigen OTLP-Collector und bekomme Traces, Metriken und Logs – die Plattform setzt die Umgebungsvariablen, das SDK deiner App macht den Rest.
Weg von Heroku Postgres, ohne Daten zu verlieren
Erstelle ein Heroku-Postgres-Backup, stelle es in einer neuen Datenbank wieder her, überprüfe jede Zeile und schalte um, ohne Downtime oder Datenverlust.
Eine Rails-App auf Hetzner deployen
Eine Rails-App auf einem Hetzner-Server mit Postgres, Caddy-HTTPS und nächtlichen Backups via Docker Compose deployen, plus ein wiederholbarer Release-Prozess.
n8n auf einem 6-Dollar-Server selbst hosten
Betreibe n8n auf deinem eigenen 6-Dollar-Droplet mit Postgres und HTTPS: das komplette Docker-Compose-Setup, Backups, Upgrades und die Ein-Klick-Abkürzung.
Was einen Deploy wirklich zero-downtime macht
Kein Marketing-Text – die konkreten mechanischen Schritte, die bedeuten, dass es nie einen Moment gibt, in dem deine App keinen funktionierenden Container hat, der eine Anfrage beantwortet.
Rails deployen, ohne ein Dockerfile zu schreiben
Die meisten Rails-Apps brauchen null Container-Konfiguration zum Deployen. Hier ist, was tatsächlich die Build-Methode wählt, und wann du wirklich eingreifen musst.
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.