Ohne Git veröffentlichen: vom ZIP zur Live-Website in wenigen Minuten

Unterstützte Stacks ohne Dockerfile

Liegt ein Dockerfile im Stammverzeichnis des ZIP, wird es statt des automatischen Rezepts verwendet. Fehlt es, zeigt das Build-Log das erzeugte Dockerfile – hilfreich, um Fehler zu verstehen und zu beheben.

Schritt für Schritt

• Erstellen Sie Ihr Konto unter devoracloud.com/register (7 Tage kostenlos, ohne Kreditkarte).
• Legen Sie im Dashboard ein neues Projekt an und wählen Sie den ZIP-Upload.
• Laden Sie die Datei hoch (bis 512 MB).
• Verfolgen Sie den Build: Analyse, Erstellung, Veröffentlichung und Healthcheck.
• Ist der Status bereit, antwortet die Website unter https://ihr-projekt.apps.devoracloud.com mit automatischem Zertifikat.

Sie möchten nichts davon selbst tun? Erzeugen Sie im Dashboard das KI-Token und lassen Sie Ihre KI veröffentlichen: Sie bereitet das ZIP vor, legt das Projekt an und verfolgt den Build für Sie.

So bauen Sie das ZIP

Legen Sie die Datei, die das Projekt kennzeichnet, ins Stammverzeichnis des ZIP: package.json, requirements.txt, go.mod oder index.html. Ein einzelner Ordner auf oberster Ebene funktioniert ebenfalls. Verwenden Sie ZIP; tar-Archive werden nicht akzeptiert.

Nicht ins ZIP gehören:

• node_modules – Abhängigkeiten werden beim Build installiert.
• .next, dist und build – der Build läuft auf der Plattform neu.
• .git – die Historie wird nicht gebraucht.
• .env und alle Dateien mit Passwörtern oder Schlüsseln – nutzen Sie die Umgebungsvariablen des Projekts.
• Uploads von Nutzern und lokale Datenbanken wie .sqlite-Dateien – Dateien gehören in S3, Daten in PostgreSQL.

Ein schlankes ZIP lädt schneller hoch und verhindert, dass Dinge in die Cloud wandern, die nur auf Ihrem Rechner Sinn ergaben.

PORT und 0.0.0.0: der häufigste Fehler

Die Anwendung muss auf der Adresse 0.0.0.0 und auf dem Port aus der Umgebungsvariable PORT lauschen. Lauscht sie nur auf localhost (127.0.0.1) oder auf einem anderen festen Port, läuft der Build zwar durch, der Healthcheck erreicht die App aber nicht – und das Deployment schlägt fehl.

• Node.js: app.listen(process.env.PORT || 3000, "0.0.0.0").
• Next.js: Das Standard-start-Skript (next start) berücksichtigt PORT bereits.
• Python: Starten Sie den Server (uvicorn, gunicorn) mit Host 0.0.0.0 und dem Port aus PORT.
• Go: Lesen Sie os.Getenv("PORT") und lauschen Sie auf ":" + Port.

Prüfen Sie auch die Skripte: In Node-Projekten braucht die package.json ein build-Skript (falls es einen Build-Schritt gibt) und ein start-Skript.

Weitere häufige Fehler beim ersten Deployment

Schlägt das Deployment fehl, öffnen Sie zuerst das Log, bevor Sie etwas ändern. Die häufigsten Fälle sind schnell behoben:

• Fehlende Abhängigkeit: Das Paket läuft auf Ihrem Rechner, weil Sie es von Hand installiert haben, steht aber nicht in package.json oder requirements.txt.
• Falsche Runtime-Version: Das Projekt braucht eine andere Node.js- oder Python-Version als die, die der Build erkannt hat.
• Groß- und Kleinschreibung in Dateinamen: Unter Windows oder macOS funktioniert es, auf dem Linux des Builds nicht.
• Umgebungsvariable fehlt beim Build: Der Code liest einen Schlüssel, der nur in Ihrer lokalen .env existierte.

Beheben Sie den Fehler, erstellen Sie ein neues ZIP und deployen Sie erneut. Die vorherige Version bleibt so lange online.

Variablen, Datenbank und S3

Passwörter und Schlüssel hinterlegen Sie als Umgebungsvariablen des Projekts; sie stehen beim Build und zur Laufzeit bereit. Nutzt die Anwendung eine Datenbank, legen Sie PostgreSQL oder Redis vor dem ersten Deployment an: Die Verbindung erreicht die App als DATABASE_URL (bzw. REDIS_URL). Für Bilder und Dokumente legen Sie den privaten S3 des Projekts an; die App erhält fertige S3_*-Variablen.

Legen Sie Geheimnisse nie in Variablen ab, die der Browser liest, etwa solche mit dem Präfix NEXT_PUBLIC_.

Neue Versionen – und GitHub später

Zum Aktualisieren laden Sie ein neues ZIP hoch und deployen erneut. Ein fehlgeschlagenes Deployment ersetzt nie die Live-Version: Die Website läuft weiter, während Sie korrigieren.

Wenn das Projekt reifer wird, verbinden Sie GitHub einmal im Dashboard unter Verbindungen und verknüpfen das Repository mit dem Projekt. Danach löst jeder Push auf den gewählten Branch ein Deployment aus. Der ZIP-Upload bleibt verfügbar, wenn Sie ihn bevorzugen.

Häufige Fragen