blitz.cloudBetaAnmeldenKostenlos starten

Ein GitHub-Projekt auf blitz.cloud ausrollen

Zeig blitz.cloud ein öffentliches GitHub-Repository, und der Code wird gebaut und mit HTTPS online gestellt. Wie der Build läuft, welcher Port gilt und was schiefgeht.

Aktualisiert

Füg den Link zu einem beliebigen öffentlichen GitHub-Repository ein, und blitz.cloud klont es, baut es und startet das Ergebnis unter deiner Adresse mit HTTPS. Es muss nicht dein Repository sein. Hat das Projekt ein Dockerfile, nutzen wir das; hat es keins, ermitteln wir aus dem Inhalt, wie sich das Projekt bauen lässt.

Schritt für Schritt

  1. Öffne beta.blitz.cloud und klick auf "Host something new".
  2. Wähl "My own code" (mein eigener Code).
  3. Füg den Link ein, zum Beispiel github.com/docker/welcome-to-docker, und klick auf Continue.
  4. Gib der App einen kurzen Namen. Daraus wird die Subdomain: demo wird zu demo.<du>.blitz.cloud.
  5. Klick auf "Build it and put it online" und schau zu.

Der erste Build dauert ein paar Minuten, weil alles, was das Projekt braucht, frisch heruntergeladen wird. Spätere Builds desselben Projekts nutzen die Schichten wieder, die sich nicht geändert haben.

Wie der Build läuft

Dein Projekt hatWas wir tun
Ein Dockerfile im Wurzelverzeichnis oder in docker/Wir bauen damit
Kein DockerfileWir erkennen die Sprache und erzeugen eins (Nixpacks)

Beides läuft in einer Sandbox ohne Zugriff auf irgendetwas von uns oder von anderen. Ein Build erreicht das Internet, um Abhängigkeiten zu laden, und nichts im privaten Netz.

Ist ein Projekt einmal gebaut, merken wir uns den Bauplan zu genau diesem Commit. Rollt jemand anderes dasselbe öffentliche Projekt beim selben Commit aus, startet der Build mit dem, was wir schon wissen. Baupläne aus privaten Repositories werden nie geteilt.

Auf welchem Port deine App lauscht

Wir sagen deiner App über die Umgebungsvariable PORT, dass sie auf 8080 lauschen soll; das nutzt auch ein erzeugter Build. Nennt dein Dockerfile mit EXPOSE einen anderen Port, lesen wir den nach dem ersten Build aus dem Image und verwenden ihn stattdessen.

Deine App muss auf einem Port über 1024 lauschen. Jede App läuft hier als uid 1000 ohne jede Linux-Capability, und ein Prozess ohne root-Rechte kann Port 80 nicht belegen.

Wenn sich dein Code ändert

Klick auf der Seite der App auf "Get the newest code". Damit wird der neueste Stand des Branches gebaut und online gestellt. Die laufende Version bleibt oben, bis die neue funktioniert, ein fehlgeschlagener Build ändert also nichts.

Automatisch bei jedem Push neu auszurollen, setzt dein verbundenes GitHub-Konto voraus, und das ist noch nicht freigeschaltet. Siehe Was ist live.

Private Repositories

Auch noch nicht. Erst ein verbundenes GitHub-Konto macht private Projekte für uns sichtbar, und das kommt zusammen mit dem automatischen Ausrollen. Heute muss das Projekt öffentlich sein.

Umgebungsvariablen und Datenbanken

Umgebungsvariablen setzt du nach dem ersten Deploy im Tab Environment der App. Sie werden verschlüsselt gespeichert und beim nächsten Neustart übernommen. Siehe Einstellungen und Dateien.

Eine verwaltete Datenbank legst du auf der Seite Databases an und verbindest sie dort mit der App. Die Erkennung dessen, was ein Projekt braucht, läuft für Docker-Images, nicht für Builds aus Quellcode. Ein Projekt, das PostgreSQL braucht, bekommt sie also, wenn du es sagst, und nicht automatisch. Siehe Datenbanken.

Typische Fehler

  • "We could not find a Dockerfile in this project": Das Projekt hat kein Dockerfile, und auch die Erkennung kam nicht weiter. Ein Dockerfile im Repository ist die verlässliche Lösung.
  • Der Build scheitert beim Installieren der Abhängigkeiten: Im Log unter der Fehlermeldung steht, was der Installer gesagt hat. Meistens passt eine Lockfile nicht zum Manifest.
  • "This build ran out of memory": Ein Build bekommt 2 GB. Große Frontend-Builds brauchen manchmal mehr, dann melde dich und wir schauen es uns an.
  • Die App bleibt auf "Starting" und antwortet nie: Sie lauscht woanders als dort, wohin wir den Verkehr schicken. Lass sie PORT lesen oder ergänze EXPOSE im Dockerfile und roll neu aus.
  • "Part of this project is built for a different kind of processor": Unsere Server sind x86. Ein Base-Image, das es nur für arm64 gibt, läuft nicht.

Das Build-Log steht im Tab Deployments der App, unter der Zeile, zu der es gehört, und bleibt danach dort.

Monorepos

Ein Projekt, eine App, gebaut aus dem Wurzelverzeichnis des Repositories. Ein Unterverzeichnis auszuwählen, geht noch nicht.

Stell heute deine erste App online.

Kostenloser Tarif, keine Kreditkarte, keine Warteliste.

Kostenloses Konto anlegen