Ein Docker-Image auf blitz.cloud ausrollen

Du kannst jedes öffentliche Docker-Image ausrollen, das für amd64 gebaut ist, ob von Docker Hub, aus der Registry von GitHub (ghcr.io), von Quay oder einer anderen öffentlichen Registry. Klick im Dashboard auf "Host something new", wähle "An app from Docker Hub" (eine App von Docker Hub), such das Image nach Namen oder gib seinen vollen Namen ein, wähl Tag und Subdomain, und blitz.cloud ermittelt den Port und startet den Container mit HTTPS davor.

Voraussetzungen an das Image

Root ist kein Problem. Jede App läuft in einer eigenen gVisor-Sandbox. Ein Image, das als Root startet, etwa das offizielle nginx, läuft als Root in dieser Sandbox und nirgends sonst. Ein Image, das einen Benutzer angibt, läuft als dieser Benutzer. Der Assistent sagt dir, wenn ein Image als Root läuft.

Eine App, die du vor dem 25. September 2026 ausgerollt hast, läuft bis zum nächsten Neustart weiter als uid 1000. Starte sie einmal über ihre Seite neu, dann startet sie so, wie ihr Image es erwartet.

Schritt für Schritt

1. Öffne dashboard.blitz.cloud und klick auf "Host something new".
2. Wähl "An app from Docker Hub" und tipp einen Teil des Namens ein, etwa uptime-kuma oder deinname/deineapp. Der Assistent durchsucht Docker Hub beim Tippen, offizielle Images sind markiert. Für eine andere Registry gibst du den vollen Namen ein, etwa ghcr.io/deinname/deineapp.
3. Wähl einen Tag. Der Assistent zeigt die echten Tags des Images 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. Mit Pro werden diese Ordner jede Nacht kopiert, im kostenlosen Tarif nur die 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.

Automatische Updates

Mit eingeschalteten automatischen Updates (Voreinstellung bei einem beweglichen Tag wie latest oder alpine) schauen wir jede Nacht gegen 4:00 UTC, wohin der Tag zeigt. In der ersten Nacht merken wir uns das nur. Ab dann stellen wir, sobald der Tag auf einen neueren Build zeigt, genau diese Version online, festgehalten über ihren Digest, damit läuft, was geprüft wurde. Startet die neue Version nicht innerhalb von zehn Minuten, stellen wir die Version davor wieder her, sagen das im Tab Activity und schalten die automatischen Updates für diese App aus, bis du sie wieder einschaltest.

Während die neue Version startet, zeigt die App Updating, und die Version davor läuft weiter. Nach jedem nächtlichen Update schicken wir dir eine Mail. Die kannst du unter Settings > Notifications abschalten.

Die Prüfung funktioniert für Images auf Docker Hub, der Registry von GitHub (ghcr.io), Quay, lscr.io, GitLab sowie den öffentlichen Registries von Amazon und Microsoft. Liegt ein Image woanders, steht das im Tab Settings der App.

Häufige Probleme

• Die App bleibt auf "Starting": Sie lauscht wahrscheinlich auf einem anderen Port als dem gewählten. Ändere ihn im Tab Settings der App unter Port.
• "This app wants to run as root": Die App wurde eingerichtet, bevor Root erlaubt war. Starte sie neu, dann läuft sie als Root in ihrer Sandbox.
• "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. Füg den Link eines öffentlichen Repositories ein, und wir bauen den Code und stellen ihn online. Verbindest du dein GitHub-Konto, gehen auch deine privaten Repositories, und bei jedem Push geht eine neue Version online. Siehe GitHub-Projekt ausrollen.