Deploy+

Deploy+.
Vom Push in die Produktion.

Verbinden Sie Ihre Repositorys von GitHub, GitLab, Bitbucket oder Gitea mit dem Hosting und vergessen Sie den letzten Schritt: Jeder Push veröffentlicht eine neue Version ohne Downtime, mit Ihren Build-Befehlen, und Zurückkehren ist ein Klick.
Tarife ansehen Anleitung lesen
tuproyecto/web · main Deploy+
  1. 01 Push
  2. 02 Build
  3. 03 Veröffentlichen
  4. 04 Online

warte auf Änderungen …

Versionen

Jede Version wird gespeichert: Zurückkehren ist ein Klick, ohne Unterbrechung.

Ein git push

und das Deployment startet von selbst, ohne das Panel zu öffnen

Keine Ausfallzeit

die neue Version geht durch das Umstellen eines Links live

Rollback in Sekunden

Sie kehren über den Verlauf zu jeder früheren Version zurück

Kostenlos

in allen Hosting-Tarifen enthalten

Funktioniert mit Ihrem Git, wo auch immer es liegt

So erstellen Sie das Token bei jedem Anbieter →
GitHub github.com · Webhook und Signatur GitLab gitlab.com oder Ihre eigene Instanz Bitbucket bitbucket.org · Webhook und Signatur Gitea / Forgejo Codeberg oder Ihre eigene Installation Anderer Git-Server jedes Repository über HTTPS

So funktioniert es

Vier Schritte, und Sie müssen sie nie wieder anfassen.

Ihr Code ist bereits versioniert. Was fehlte, war das letzte Stück: ihn in die Produktion zu bringen, ohne Dateien von Hand hochzuladen oder die Daumen zu drücken.

Verbinden

Ihr Repository, egal wo es liegt

GitHub, GitLab, Bitbucket, Gitea oder jedes Git über HTTPS, öffentlich oder privat, mit einem Nur-Lese-Token. Bevor es weitergeht, fragt das Panel die API ab und zeigt Ihnen das Repository, seine Branches und was derzeit im Zielordner liegt.
https:// schreibgeschütztes Token Zugriff geprüft

auch in den Konten eines Multi-Account-Tarifs

Fünf Anbieter, ein Ziel

über HTTPS
Deploy+

Push

Push, und das Deployment startet von selbst

Den Webhook legen wir beim Verbinden des Repositorys an, und jede Benachrichtigung kommt signiert an. Wenn Sie selbst entscheiden möchten, wann, starten Sie es per Schaltfläche oder aus Ihrer Continuous Integration mit dem Deployment-Link.
Das Übliche
Dateien von Hand hochladen und die Daumen drücken
Hier
Ein Push, und GitHub benachrichtigt den Server

Vom Push zum Deployment

signierter Webhook
Ein Push auf den Branch meldet sich per Webhook, und das Deployment startet von selbst GITHUB · PUSH main · a91f3c2 fix: Checkout mit Gutschein POST · HMAC HOSTSUAR · DEPLOY+ Signatur geprüft Branch main: wird bereitgestellt Deployment #48 läuft
Signierte Benachrichtigung · Deploy #48 in der Warteschlange

Veröffentlichen

Atomares Deployment, ohne Unterbrechung

Jede Version wird in einen eigenen Ordner geklont, Ihre .env und Ihre gemeinsamen Ordner werden verlinkt und Ihr Skript wird ausgeführt. Nur wenn alles geklappt hat, wird veröffentlicht: Ein Link ändert sich, und die vorherige Version bleibt erhalten.

0 s

Ausfallzeit: Die neue Version wird durch das Umstellen eines Links veröffentlicht

Atomares Deployment

~/deploy/tienda/

releases/

├─ 20260904-1830 · veröffentlicht

└─ 20260905-1012 · Klonen und Skript ausführen…

shared/

├─ .env → in jeder Version verlinkt

└─ storage/ → in jeder Version verlinkt

current → releases/20260904-1830

Neue Version wird vorbereitet; die bisherige bleibt online

Zurückkehren

Rollback per Klick, aus dem Verlauf

Datum, wer es ausgelöst hat, Commit, Dauer und das vollständige Protokoll jedes Deployments. Die letzten Versionen bleiben auf dem Server: Die Rückkehr zu einer davon dauert Sekunden, weil nichts geklont werden muss.

5 Versionen

standardmäßig aufbewahrt; Sie entscheiden, wie viele

Vollständige Anleitung lesen

Deployment-Verlauf

5 gespeicherte Versionen
DatumAuslöserZeit
heute 10:12 · a91f3c2 Push 38 s
gestern 18:30 · e07b9d4 Manuell 41 s
gestern 11:05 · 4c1d8e7 Rollback 2 s
Mo 09:48 · 4c1d8e7 Push 35 s

gestern 18:30 · e07b9d4

die Version bleibt auf dem Server

Zu dieser Version zurückkehren

Assistent

Es erkennt das Projekt und bereitet es vor.

Sie wählen den Projekttyp, und der Assistent schlägt Web-Root, Skript, gemeinsame Ordner und eine eventuell nötige Datenbank vor. Danach passen Sie es selbst an.

  • PHP

    Laravel

    Composer, optimierte Caches und Veröffentlichung aus public.

    Web-Stammverzeichnis
    public/
    Gemeinsam
    storage
    Datenbank
    bereitet sie vor
    Assets mit Node
    wenn Sie es anhaken

  • PHP

    Symfony

    Composer, Umgebung prod und Veröffentlichung aus public.

    Web-Stammverzeichnis
    public/
    Gemeinsam
    var/log
    Datenbank
    bereitet sie vor
    Assets mit Node
    wenn Sie es anhaken

  • PHP

    WordPress

    Datenbank, wp-config.php und dauerhafte Uploads.

    Web-Stammverzeichnis
    Root
    Gemeinsam
    wp-content/uploads, wp-config.php
    Datenbank
    bereitet sie vor
    Assets mit Node
    wenn Sie es anhaken

  • PHP

    PHP / Composer

    Eine saubere Basis für PHP-Anwendungen mit Composer.

    Web-Stammverzeichnis
    Root
    Gemeinsam
    —
    Datenbank
    bereitet sie vor
    Assets mit Node
    wenn Sie es anhaken

  • Statisch

    Kompiliertes Frontend

    Kompiliert mit Node und veröffentlicht das Ergebnis aus dist.

    Web-Stammverzeichnis
    dist/
    Gemeinsam
    —
    Datenbank
    nicht nötig
    Assets mit Node
    immer

  • Statisch

    Statisches HTML

    Veröffentlicht das Repository unverändert, ohne etwas zu installieren.

    Web-Stammverzeichnis
    Root
    Gemeinsam
    —
    Datenbank
    nicht nötig
    Assets mit Node
    —

  • Individuell

    Anderes Projekt

    Keine Annahmen: Sie bestimmen Root, Skript und Persistenz.

    Web-Stammverzeichnis
    Root
    Gemeinsam
    —
    Datenbank
    bereitet sie vor
    Assets mit Node
    wenn Sie es anhaken

Was enthalten ist

Was es braucht, um ernsthaft zu deployen.

Fünf Entscheidungen der Engine, die man bei einem beliebigen „Deploy aus Git“ nicht sieht und die Sie an dem Tag merken, an dem etwas schiefgeht.

Skript und Node

Ihre Befehle, bei jeder Version, mit Node, falls nötig

Composer, npm, artisan … Befehl für Befehl oder als komplettes Bash-Skript, mit dem Commit, den Pfaden und Ihrer .env als Variablen. Wenn Node verwendet wird und das Konto es nicht hat, wird es vorher installiert.
Composer npm ci artisan Node über NVM

schlägt ein Befehl fehl, bleibt die vorherige Version online

Deployment-Skript

Vorlage · Laravel
Laravel Symfony WordPress PHP Node / Vite Keine

composer install --no-dev --prefer-dist --optimize-autoloader

npm ci && npm run build # Node wird bei Bedarf über NVM installiert

php artisan migrate --force # optional: Das Rollback macht Daten nicht rückgängig

php artisan config:cache && php artisan route:cache

Wenn ein Befehl fehlschlägt, stoppt das Deployment und die vorherige Version bleibt online.

Datenbank

Die Datenbank, beim Verbinden angelegt

Wählen Sie „auch die Datenbank vorbereiten“, und Deploy+ legt eine leere MySQL-Datenbank und einen eigenen Benutzer an und schreibt die Verbindung in Ihre .env oder wp-config.php. Das Passwort wird nirgends gespeichert.

MySQL

Datenbank, Benutzer und Datei in einem Schritt

Datenbank · beim Verbinden

bereit
  • Leere MySQL-Datenbank mi_app
  • Eigener Benutzer mit allen Rechten mi_app_usr
  • Verbindung in .env eingetragen ohne etwas von Hand anzufassen

DB_DATABASE=mi_app

DB_USERNAME=mi_app_usr

DB_PASSWORD=•••••••••••• # wird nicht im Panel gespeichert

Konfiguration

Die .env und die Uploads überstehen jede Version

Die .env bleibt automatisch erhalten und Sie bearbeiten sie im Panel. Die Pfade, die Sie markieren, etwa storage oder uploads, liegen in shared und werden in jeder neuen Version verlinkt. Das Projektprofil schlägt seine eigenen bereits vor.
Das Übliche
Uploads und .env im Code, jedem Deployment ausgeliefert
Hier
Außerhalb des Codes: Weder ein Deployment noch ein Rollback rührt sie an

Gemeinsam für alle Versionen

~/deploy/tienda/

shared/ → releases/20260905-1012/

.envbearbeitbar

storage/aus dem Profil

public/uploads/Ihre

In jede neue Version verlinkt; auch ein Rollback rührt sie nicht an.

Konsole

Live-Konsole und Befehle auf dem Veröffentlichten

Während des Deployments sehen Sie jeden Schritt mit seiner Dauer und, falls etwas fehlschlägt, die letzten Zeilen. Danach führen Sie bei Bedarf einen Befehl auf der veröffentlichten Version aus, ohne ein Terminal zu öffnen.

6 Schritte

verbinden, klonen, geteilt, Skript, aktivieren, aufräumen

Einen Befehl ausführen

über current · max. 2 Min.
$php artisan queue:restart Ausführen

~/deploy/tienda/current

$ php artisan queue:restart

Broadcasting queue restart signal.

✓ fertig in 0,4 s

Sicherheit

Ein Token mit dem Nötigsten, verschlüsselt und nicht im Log

Das Repository lesen und, wenn wir den Webhook anlegen sollen, Webhooks verwalten. Sonst nichts. Jede Push-Benachrichtigung wird anhand der Signatur des Anbieters geprüft.
schreibgeschützt verschlüsselt HMAC-Signatur

Widerrufen Sie ihn jederzeit: Nur das Deployment funktioniert dann nicht mehr

Token-Berechtigungen

das Minimum, und verschlüsselt
AnbieterKlonenWebhook
GitHubcontents + metadata · read+ webhooks
GitLabread_repository+ api
Bitbucketrepositories · read+ webhooks
Gitea / ForgejoLesen+ webhooks
Anderes GitBenutzer + Token—

Verschlüsselt, nur zum Klonen, nie im Log.

All das ist in allen Hosting-Tarifen und in den Konten eines Multi-Account-Tarifs enthalten, ohne Aufpreis.

Vollständige Anleitung lesen →

Fragen

Bevor Sie das erste Repository verbinden.

In welchen Tarifen ist Deploy+ enthalten?

In allen Hosting-Tarifen, ohne Aufpreis. Das Tool finden Sie im Kundenbereich bei den Optionen Ihres Hosting-Dienstes.

Funktioniert es mit privaten Repositorys?

Ja, mit öffentlichen und privaten Repositorys. In beiden Fällen brauchen Sie ein GitHub-Zugriffstoken: Erstellen Sie ein fine-grained Token, beschränkt auf das Repository, das Sie deployen wollen, mit den Berechtigungen Contents: Read-only und Metadata: Read-only. Schreibrechte auf Ihren Code benötigen wir nicht.

Ist meine Website während des Deployments offline?

Nein. Jedes Deployment wird in eine neue Version geklont, die gemeinsam genutzten Dateien werden verknüpft, und Ihre Skripte laufen bevor die Version veröffentlicht wird. Erst wenn alles geklappt hat, wird der symbolische Link current auf die neue Version umgestellt, und dieser Wechsel erfolgt sofort. Schlägt ein Skript fehl, bricht das Deployment ab, und die vorherige Version bleibt online.

Wie kehre ich zur vorherigen Version zurück, wenn etwas schiefgeht?

Im Verlauf, mit der Schaltfläche Rollback bei einem beliebigen früheren Deployment. Das dauert nur Sekunden, weil nichts geklont wird: Es ändert sich nur, auf welche Version current zeigt. Standardmäßig werden die letzten 5 Versionen aufbewahrt, und Sie können einstellen, wie viele Sie behalten möchten.

Kann ich composer, npm oder artisan-Befehle ausführen?

Ja. Jedes Repository hat einen Skript-Editor, in dem Sie die Befehle festlegen, die in jeder Version vor der Veröffentlichung ausgeführt werden: composer install --no-dev, npm run build, php artisan config:cache … Das System filtert gefährliche Befehle heraus. Um Node.js und npm zu nutzen, installieren Sie sie zuerst über den Paketmanager von cPanel.

Was passiert mit der .env und den Upload-Ordnern?

Sie gehen zwischen den Deployments nicht verloren. Die .env wird automatisch erkannt und beibehalten, und Sie können beliebige Pfade (storage/app, uploads …) als gemeinsam genutzte Dateien hinzufügen: Sie werden separat gespeichert und in jeder neuen Version verknüpft.

Ihr nächster Push, schon bereitgestellt.

Deploy+ ist in allen Hosting-Tarifen enthalten, in den Optionen Ihres Dienstes. Wenn Sie von einem anderen Anbieter kommen, helfen wir Ihnen bei der Einrichtung.
Tarife ansehen Kontakt aufnehmen