blitz.cloudBetaAnmeldenKostenlos starten

Ein Docker-Image auf blitz.cloud ausrollen

Jedes öffentliche Docker-Hub-Image auf blitz.cloud mit HTTPS, Umgebungsvariablen und dauerhaftem Speicher starten. Voraussetzungen, Ports und typische Fehler.

Aktualisiert

Du kannst jedes öffentliche Docker-Image von Docker Hub ausrollen, das für amd64 gebaut ist. Klick im Dashboard auf "Host something new", wähle "An app that is already packaged up" (eine schon verpackte App), such das Image nach Namen, wähl Tag und Subdomain, und blitz.cloud ermittelt den Port und startet den Container mit HTTPS davor.

Voraussetzungen an das Image

VoraussetzungWarum
Öffentliches Repository auf Docker HubDer Assistent durchsucht Docker Hub. Private Images und andere Registries (ghcr.io, quay.io) lassen sich noch nicht auswählen.
Gebaut für linux/amd64Unsere Server sind x86. Ein Image nur für arm64 startet nicht.
Läuft als normaler Benutzer ohne RootJede App läuft als uid 1000, Gruppe 1000, ohne Linux-Capabilities.
Liefert HTTP auf einem TCP-PortBesucher erreichen diesen Port über HTTPS auf deiner Adresse.

An der Root-Regel scheitern die meisten. Viele offizielle Images starten als Root und wechseln erst im Entrypoint den Benutzer oder schreiben beim Start in Systemordner. Die stoppen auf blitz.cloud. Such nach einer "unprivileged"- oder "rootless"-Variante, zum Beispiel nginxinc/nginx-unprivileged statt nginx.

Wir empfehlen Images, die auf einem Port über 1024 lauschen, etwa 8080. Ein Prozess ohne Root darf Port 80 meist nicht belegen.

Schritt für Schritt

  1. Öffne beta.blitz.cloud und klick auf "Host something new".
  2. Wähl "An app that is already packaged up" und tipp einen Teil des Namens ein, etwa uptime-kuma oder deinname/deineapp. Offizielle Images sind markiert.
  3. Wähl einen Tag. Der Assistent zeigt die echten Tags von Docker Hub und wählt den vor, der neuen Releases folgt, etwa latest oder eine Hauptversion.
  4. Gib der App einen kurzen Namen. Daraus wird die Subdomain: backend wird zu backend.<du>.blitz.cloud.
  5. Prüf, was blitz.cloud erkannt hat, und klick auf "Put it online".

Ein Repository, das du vor ein paar Minuten gepusht hast, taucht vielleicht nicht sofort in der Docker-Hub-Suche auf. Docker Hub nimmt neue Repositories mit etwas Verzögerung in den Suchindex auf.

Was blitz.cloud erkennt

Wenn du ein Image wählst, lesen wir, was das Image über sich selbst angibt: freigegebene Ports, Volumes und Namen von Umgebungsvariablen. Ein Sprachmodell ergänzt, was die Metadaten nicht verraten, etwa "WordPress will MariaDB und liest WORDPRESS_DB_HOST". Bei den Ports hat das Image das letzte Wort. Schlägt das Modell einen Port vor, den das Image nicht freigibt, gewinnt das Image.

Der Port wird in dieser Reihenfolge gewählt:

  1. Ein Port, den das Image mit EXPOSE angibt
  2. Gibt es mehrere: 80, 8080, 3000, 8000, 5000, sonst der niedrigste
  3. Gibt es keinen, der Vorschlag des Modells
  4. Ist gar nichts bekannt, 80

Port, Datenbank und die dauerhaft gespeicherten Ordner kannst du im Assistenten unter "Advanced settings" überschreiben. Der Bereich ist standardmäßig zu, weil die meisten Images ihn nicht brauchen.

Umgebungsvariablen

Umgebungsvariablen setzt du im Tab Environment der App. Sie werden verschlüsselt, bevor sie gespeichert werden, und jede App kann bis zu 64 haben. Änderungen wirken beim nächsten Neustart der App, und der Neustart-Knopf steht direkt neben diesem Hinweis. Siehe Einstellungen und Dateien.

Datenbanken

Braucht das Image eine Datenbank, kann blitz.cloud eine anlegen und die Verbindungsdaten als Umgebungsvariablen übergeben. Sind die Variablennamen bekannt, werden sie für dich ausgefüllt und vorher angezeigt. Sind sie nicht bekannt, bekommt die App DATABASE_URL. Siehe Datenbanken.

Dauerhafter Speicher

Ordner, die das Image als Volumes angibt, und alle, die die Erkennung ergänzt, überstehen Neustarts. Eine App aus einem Docker-Image kann bis zu 6 Ordner behalten und reserviert 1 GB deines Speichers. Dateien werden noch nicht gesichert, nur Datenbanken.

Health Checks

Bei einem Docker-Image prüfen wir, ob der Port Verbindungen annimmt, bevor Traffic dorthin geht. Einen automatischen Neustart gibt es für solche Images nicht, weil ein Neustart einer App, die niemand geprüft hat, etwas kaputt machen kann, das gerade funktioniert. Apps aus dem App Store bekommen einen richtigen HTTP-Check und werden neu gestartet, wenn sie nicht mehr antworten.

Häufige Probleme

  • Die App bleibt auf "Starting": Sie lauscht wahrscheinlich auf einem anderen Port als dem gewählten. Den Port einer bestehenden App kann das Dashboard noch nicht ändern, also lösch die App und roll sie mit dem richtigen Port unter Advanced settings neu aus.
  • "This app insists on running with full access to the machine": Das Image braucht Root. Nimm eine Variante ohne Root.
  • "Needs attention" mit Crash-Loop: Lies die letzten Log-Zeilen auf der Seite. Meist fehlen Umgebungsvariablen, oder die App schreibt in geschützte Ordner.
  • "There is no room on blitz.cloud for this app right now": Der Cluster ist voll. Wir fügen dann Server hinzu, versuch es später noch einmal.

Mehr unter App-Status und Logs.

Kann ich stattdessen aus GitHub ausrollen?

Ja, bei einem öffentlichen Repository: Link einfügen, und wir bauen den Code und stellen ihn online. Siehe GitHub-Projekt ausrollen. Private Repositories und das Ausrollen bei jedem Push setzen dein verbundenes GitHub-Konto voraus, und das ist noch nicht freigeschaltet (Was schon geht).

Stell heute deine erste App online.

Kostenloser Tarif, keine Kreditkarte, keine Warteliste.

Kostenloses Konto anlegen