Automatisierung

Einmal skripten, überall ausführen

Q: Soll ich die Deploy-URL, die CLI oder die API nutzen?

Die Deploy-URL ist am einfachsten: ein `curl -X POST`, kein Token, aber deine Pipeline erfährt nicht, ob der Deploy erfolgreich war. Die CLI mit `--watch` wartet und lässt den Job bei einem fehlgeschlagenen Deploy scheitern. Die API bietet dir dasselbe in deinen eigenen Skripten.

Starte Deploys aus deiner Pipeline und lass den Build fehlschlagen, wenn der Deploy fehlschlägt. Führe dasselbe Bash-Skript mit einem Klick auf jedem Server aus und informiere deine eigenen Systeme über jeden Deploy.

Jetzt deployen Dokumentation lesen

Vier Wege, einen Deploy ohne Klick zu starten

Push to Deploy
Verknüpfe ein Repository bei GitHub, GitLab oder Bitbucket, und ein Webhook wird für dich angelegt. Pushes auf den Branch der Site werden deployt, andere Branches ignoriert.
Deploy-URL
Ein POST an eine geheime URL, kein Token nötig. Die Antwort ist 202, 409, wenn bereits ein Deploy läuft, oder 422. Du kannst die URL jederzeit neu erzeugen.
Deploy-CLI
deploy deploy shop.example.com --watch startet den Deploy, streamt seine Ausgabe und beendet sich mit seinem Ergebnis.
REST-API
Lege per POST ein Deployment an und verfolge dann seine Aufgabe, bis sie erfolgreich ist oder fehlschlägt. JSON rein, JSON raus, 120 Anfragen pro Minute und Token.

CLI

Deploy aus GitHub Actions in einem Schritt

Die CLI ist eine einzelne PHP-Datei ohne Abhängigkeiten, die du von deiner Vimonto-Deploy-Adresse unter /cli/deploy herunterlädst. Die Ubuntu-Runner von GitHub haben PHP bereits an Bord, du musst also nichts installieren.

Erstelle einen Token nur mit dem Scope Deploy und speichere ihn als Secret. Mit --watch färbt ein fehlgeschlagener Deploy die Pipeline rot. Derselbe Befehl funktioniert auch in GitLab CI.

.github/workflows/deploy.yml

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy shop.example.com
        run: php bin/deploy deploy shop.example.com --watch
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
          DEPLOY_URL: https://deploy.example.com
          DEPLOY_ORG: acme

REST-API

Eine API für deine eigenen Skripte

Persönliche API-Tokens handeln in deinem Namen: Sie können, was deine Rolle erlaubt, auf den Servern, die deine Teams dir geben, innerhalb der Scopes, die du wählst. Lesen zeigt an, Deploy startet und verfolgt Deploys für die CI, und Schreiben erstellt und entfernt zusätzlich Datenbanken und führt Backups und Rezepte aus. Tokens laufen nach 30, 90 oder 365 Tagen ab oder nie, und gespeichert wird nur ein Hash.

Längere Arbeit läuft als Aufgabe, deren Status, Schritt, Fortschritt und Ausgabe du mit GET /tasks/<id> abfragst. Fehler kommen als JSON mit einer Meldung, und 409-Antworten enthalten die ID der laufenden Aufgabe.

Server, Sites und Deployments auflisten; eine Site über ihre Domain finden
Deploys starten und ihre Aufgaben verfolgen
Datenbanken erstellen und löschen
Backups auflisten und sofort eines ausführen
Rezepte auflisten und auf mehreren Servern ausführen

API-Referenz

MCP

Lass deinen KI-Assistenten deployen

Vimonto Deploy hat einen eingebauten MCP-Server, sodass Assistenten wie Claude Code, Claude Desktop, Cursor und VS Code deine Server und Sites auflisten, eine Site deployen und das Deployment verfolgen, die Ausgabe einer fehlgeschlagenen Aufgabe lesen, Datenbanken anlegen sowie Backups und Rezepte ausführen können.

Er meldet sich mit einem persönlichen API-Token an: Der Assistent kann genau das, was die Scopes des Tokens und deine Rolle erlauben, auf den Servern, auf die du Zugriff hast. Löschen ist darüber nicht möglich.

Einen Assistenten verbinden

Rezepte

Gespeicherte Bash-Skripte für jeden Server

Ein Rezept ist ein Bash-Skript, das du einmal schreibst und auf einem oder mehreren aktiven Servern ausführst, als root oder als Serverbenutzer. Jeder Server bekommt eine eigene Aufgabe, sodass du jede Ausgabe getrennt verfolgst, und auf Wunsch erhältst du einen E-Mail-Bericht, wenn alle fertig sind.

Variablen wie {{server_name}}, {{ip_address}}, {{private_ip_address}} und {{server_type}} werden pro Server direkt vor dem Ausführen eingesetzt.

Rezept: Speicherplatz freigeben

set -e
echo "Cleaning up on {{server_name}} ({{ip_address}})"
apt-get autoremove -y
journalctl --vacuum-time=14d
df -h /

Deploy-Hooks

Informiere deine eigenen Systeme über jeden Deploy

Aktiviere den Deploy-Hook einer Site, und Vimonto Deploy sendet nach jedem Deploy, ob erfolgreich oder fehlgeschlagen, einen POST mit JSON an deinen HTTPS-Endpunkt, ohne den Deploy aufzuhalten. Nutze ihn für einen Chatbot, ein Changelog oder ein Automatisierungstool und prüfe ihn mit Deploy-Hook testen.

Lieber per E-Mail? Füge bis zu 10 Adressen hinzu, auch außerhalb der Organisation, die eine E-Mail erhalten, sobald ein Deploy der Site fehlschlägt.

Payload des Deploy-Hooks (gekürzt)

{
    "event": "deployment.succeeded",
    "site": { "id": 12, "domain": "shop.example.com" },
    "server": { "id": 3, "name": "web-1" },
    "deployment": {
        "status": "succeeded",
        "branch": "main",
        "commit_message": "Fix the checkout total"
    }
}

Fragen zur Automatisierung

Soll ich die Deploy-URL, die CLI oder die API nutzen?

Die Deploy-URL ist am einfachsten: ein curl -X POST, kein Token, aber deine Pipeline erfährt nicht, ob der Deploy erfolgreich war. Die CLI mit --watch wartet und lässt den Job bei einem fehlgeschlagenen Deploy scheitern. Die API bietet dir dasselbe in deinen eigenen Skripten.

Kann ich Server oder Sites über die API erstellen?

Noch nicht. Die API liest Server, Sites, Deployments, Datenbanken, Backups, Rezepte und Aufgaben, startet Deploys, erstellt und entfernt Datenbanken und führt Backups und Rezepte aus.

Was braucht die CLI?

PHP 8.2 oder neuer mit der curl-Erweiterung und einen API-Token. Sie läuft unter macOS, Linux und WSL und braucht keinen SSH-Zugang zu deinen Servern: Sie spricht nur über HTTPS mit der API.

Warum bekommt meine Pipeline einen 409?

Es lief bereits ein Deploy der Site, oft weil Push to Deploy ihn gestartet hat. Schalte Bei jedem Push deployen für Sites ab, die von der CI deployt werden.

Wer darf Rezepte ausführen?

Owner, Administratoren, Manager und Developer. Auf ihre Teams beschränkte Mitglieder können Rezepte nur auf ihren eigenen Servern ausführen. Siehe Sicherheit und Teams.

Dein nächster Deploy ist live, bevor dein Kaffee fertig ist.

Erstelle eine Organisation, verbinde einen Server und pushe. Mehr nicht.

Jetzt deployen Doku lesen