Setzen Sie WordPress auf Cipi ein: benutzerdefinierte App & GitHub automatische Bereitstellung

Von Andrea Pollastri · Letzte Aktualisierung: 22. August 2026 · Kostenlose Lektüre, keine Paywall

Cipi ist Laravel-zuerst, beherbergt aber auch WordPress als benutzerdefinierte App: isolierter Linux-Benutzer, PHP-FPM-Pool, Nginx vhost, Git-Pull in htdocs. Dieser Leitfaden führt Sie von einem leeren Ubuntu VPS zu einer Site, die sich bei jedem Push selbst bereitstellt main.

Warum eine benutzerdefinierte App (nicht Laravel)

Cipi unterstützt zwei App-Typen. Der Standardwert ist Laravel: eigener Systembenutzer, PHP-FPM oder Octane, MariaDB, .env, Supervisor Arbeiter, Crontab und Null Ausfallzeiten Bereitstellungsversionen unter current/shared. WordPress ist nichts davon.

A benutzerdefinierte App (cipi app create --custom) hat die richtige Form:

• Klassische Bereitstellung in htdocs – nein current/shared Symlink-Tausch. cipi deploy blog zieht das Repo hinein /home/blog/htdocs.
• Nginx ist bereits WordPress-ready: index index.html index.php und try_files $uri $uri/ /index.php?$args.
• Git ist optional. Überspringen Sie das Repository für reine SFTP-Uploads. Befestigen Sie später eines mit cipi app edit blog --repository=….
• Keine Datenbank, nein .env, keine cron, keine Warteschlangen bis Sie sie hinzufügen. WordPress benötigt eine Datenbank – diese erstellen Sie im nächsten Schritt.

So strukturieren Sie das WordPress-Repo

Behandeln Sie Git als die Quelle der Wahrheit für Code, nicht für Geheimnisse oder Medien. Ein Repo, das die automatische Bereitstellung übersteht, sieht folgendermaßen aus:

wordpress-site/
  .gitignore
  .github/workflows/deploy.yml
  wp-admin/
  wp-includes/
  wp-content/themes/your-theme/
  wp-content/plugins/your-plugin/
  wp-config-sample.php
  index.php
  …

Geben Sie das ein .gitignore Daher überschreibt ein Pull niemals den Status der Live-Site:

wp-config.php
wp-content/uploads/
wp-content/cache/
wp-content/upgrade/
wp-content/backup-db/
.htaccess

Weil benutzerdefinierte Apps eingebunden werden htdocs Anstatt ein Release-Verzeichnis auszutauschen, Nicht verfolgte Dateien bleiben auf der Festplatte. So werden Uploads und wp-config.php Überlebe jeden Einsatz.

• Kern in Gitist der einfachste Agentur-Workflow: Theme, Plugins und WordPress selbst gemeinsam versioniert.
• Composer / Bedrock Funktioniert auch – eingestellt --docroot=web (oder public), wenn sich der Front-Controller nicht im Repo-Root befindet.
• Machen Sie keine Produktionsgeheimnisse. Salze auf dem Server generieren; Schiebe niemals ein Leben wp-config.php.

Erstellen Sie die benutzerdefinierte App

Cipi muss bereits auf einem frischen Ubuntu VPS installiert sein:

SSH in as cipi, dann sudo -s. Erstellen Sie die WordPress-App nicht interaktiv (PHP 8.3 passt sicher zu den aktuellen WordPress; später im laufenden Betrieb austauschen). cipi app edit):

$ cipi app create --custom --user=blog \
    --domain=blog.example.com \
    --repository=git@github.com:you/wordpress-site.git \
    --branch=main \
    --php=8.3

Das sieht vor:

• Linux-Benutzer blog und Zuhause /home/blog
• PHP-FPM-Pool auf 8.3 und ein Nginx vhost für blog.example.com
• SSH-Bereitstellungsschlüssel für das Repository
• Deployer-Konfiguration, die eingebunden wird /home/blog/htdocs

Wenn Sie zuerst einen GitHub Personal Access Token gespeichert haben, fügt Cipi automatisch auch den Bereitstellungsschlüssel und einen Provider webhook hinzu:

$ cipi git github-token ghp_xxxxxxxxxxxxxxxxxxxx
$ cipi git status

Es werden feinkörnige Token benötigt Verwaltung und Webhooks eingestellt auf Lesen und schreiben auf dem Ziel-Repo; Klassische Token benötigen das repo Umfang. Einzelheiten finden Sie im Git-Auto-Setup Dokumente.

Nur SFTP (noch kein Git) – lassen Sie das Repository weg und laden Sie es hoch ~/htdocs als App-Benutzer:

$ cipi app create --custom --user=blog --domain=blog.example.com --php=8.3

Datenbank, DNS und SSL

Benutzerdefinierte Apps erhalten keine Datenbank. Erstellen Sie eine, nachdem die App existiert – MariaDB ist die Standardeinstellung und was WordPress erwartet:

$ cipi db create --name=blog

Cipi druckt den Datenbanknamen, den Benutzer, das Passwort und a mariadb+ssh:// URL für TablePlus oder DBeaver. Kopieren Sie diese Werte. sie gehen hinein wp-config.php auf dem Server, nicht in Git.

Punkt DNS A Aufzeichnungen für blog.example.com und www.blog.example.com am VPS, dann:

$ cipi alias add blog www.blog.example.com
$ cipi www add blog
$ cipi ssl install blog

cipi ssl install stellt ein Let’s Encrypt-Zertifikat aus, das jeden Alias ​​(SAN) abdeckt, und aktiviert die HTTPS-Weiterleitung. cipi www Hält Apex und www kanonisch. Siehe SSL und www-Weiterleitungen.

Zuerst bereitstellen und wp-config.php

Rufen Sie das Repository einmal ab und schreiben Sie dann die Konfiguration als App-Benutzer, damit der Dateieigentum korrekt bleibt:

$ cipi deploy blog
$ su - blog
blog@server:~$ cd ~/htdocs
blog@server:~/htdocs$ cp wp-config-sample.php wp-config.php
blog@server:~/htdocs$ nano wp-config.php

Mindestproduktionswerte (verwenden Sie die Anmeldeinformationen von cipi db create):

define('DB_NAME', 'blog');
define('DB_USER', 'blog');
define('DB_PASSWORD', 'the-password-cipi-printed');
define('DB_HOST', '127.0.0.1');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

define('DISALLOW_FILE_EDIT', true);
define('DISABLE_WP_CRON', true);
define('WP_MEMORY_LIMIT', '256M');

Erzeugen Sie neue Salze aus api.wordpress.org/secret-key und fügen Sie sie anstelle der Platzhalter ein. Offen https://blog.example.com und beenden Sie den WordPress-Installer im Browser.

GitHub Aktionspipeline (empfohlen)

Der Laravel Agent webhook (https://your-app.com/cipi/webhook) ist eine Route drinnen eine Laravel-App. Es existiert nicht auf WordPress. Für die automatische Bereitstellung müssen Sie GitHub SSH auf dem Server haben und ausführen cipi deploy – das Gleiche Pipeline-SSH-Bereitstellung Cipi Dokumente für Gated Laravel Releases.

Wählen Sie einen Auslöser. Wenn Git Auto-Setup bereits einen Anbieter webhook erstellt hat, deaktivieren Sie ihn (oder erstellen Sie nie einen), bevor Sie Aktionen hinzufügen. Zwei Bereitstellungen im selben Push-Kampf um die Sperrdatei.

1. Dedizierter SSH-Schlüssel für CI

Generieren Sie einen ed25519-Schlüssel auf Ihrem Laptop. Fügen Sie die hinzu öffentlich Schlüssel zum Server; Speichern Sie die privat Schlüssel als GitHub-Geheimnis. Verwenden Sie Git-Bereitstellungsschlüssel oder Ihren persönlichen SSH-Schlüssel nicht wieder.

# on your laptop
$ ssh-keygen -t ed25519 -C "ci-deploy-blog" -f ~/.ssh/ci_deploy_blog -N ""
$ ssh-copy-id -i ~/.ssh/ci_deploy_blog.pub cipi@your-server-ip
$ cat ~/.ssh/ci_deploy_blog

Im GitHub-Repository: Einstellungen → Geheimnisse und Variablen → Aktionen. Erstellen:

• SERVER_HOST — VPS IP oder Hostname
• SERVER_SSH_KEY — vollständiger Inhalt des privaten Schlüssels

2. Workflow-Datei

Geben Sie das hier ein .github/workflows/deploy.yml:

name: Deploy WordPress

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Guard tracked secrets
        run: |
          if git ls-files --error-unmatch wp-config.php >/dev/null 2>&1; then
            echo "wp-config.php must not be committed"
            exit 1
          fi

      - name: PHP syntax
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          coverage: none
      - name: Lint theme and plugins
        run: |
          find wp-content/themes wp-content/plugins -name '*.php' -print0 \
            | xargs -0 -n1 php -l

  deploy:
    runs-on: ubuntu-latest
    needs: check
    steps:
      - name: Deploy via Cipi
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: cipi
          key: ${{ secrets.SERVER_SSH_KEY }}
          script: sudo cipi deploy blog

Was Ihnen das bringt:

• Ein Qualitätstor – ein engagierter wp-config.php oder ein PHP-Analysefehler erreicht nie VPS.
• Ein Befehl auf dem Server — Cipi Züge main hinein htdocs mit der PHP-Binärdatei der App.
• Manuelle Wiedergabe — workflow_dispatch Stellt denselben Commit ohne weiteren Push erneut bereit.

Schützen main: keine direkten Pushs, erforderliche Statusprüfungen, kurzlebige Zweige. Die gleichen stammbasierten Gewohnheiten wie die Laravel CI/CD Anleitung, ohne so zu tun, als hätte WordPress Pest und Pint.

Sehen Sie sich die Bereitstellung vom Server aus an:

$ cipi app logs blog --type=deploy

3. Optional: Backup vor der Veröffentlichung

WordPress Schemaänderungen sind oft irreversibel. Zuerst Snapshot MariaDB, dann bereitstellen:

          script: |
            sudo cipi db backup blog
            sudo cipi deploy blog

Wiederherstellen mit cipi db restore blog backup.sql.gz wenn eine Veröffentlichung schlecht wird. Benutzerdefinierte Apps haben keinen Release-Symlink, auf den ein Rollback zurückgesetzt werden kann – der Datenbank-Dump ist Ihre Schaltfläche zum Rückgängigmachen. Siehe cipi db.

Einfacherer Weg: Git-Auto-Setup

Wenn Sie keine CI-Gates benötigen (Solo-Site, vertrauenswürdige Commits), überspringen Sie Aktionen und lassen Sie Cipi GitHub für Sie verdrahten:

$ cipi git github-token ghp_xxxxxxxxxxxxxxxxxxxx
$ cipi app create --custom --user=blog --domain=blog.example.com \
    --repository=git@github.com:you/wordpress-site.git --branch=main --php=8.3

Auf app create, Cipi fügt den SSH-Bereitstellungsschlüssel und ein webhook zum Repository hinzu. Die Zusammenfassung zeigt automatisch konfiguriert ✓. Ein Anstoß dazu main dann läuft es genauso cipi deploy Pipeline ohne YAML-Datei.

Wenn Sie die App vor dem Speichern eines Tokens erstellt haben, drucken Sie die Werte aus und fügen Sie sie manuell hinzu:

$ cipi deploy blog --key       # Settings → Deploy keys
$ cipi deploy blog --webhook   # Settings → Webhooks

Cron, Backups und alltägliche Operationen

Ersetzen Sie WP-Cron durch System cron

Benutzerdefinierte Apps erhalten keine Crontab. Mit DISABLE_WP_CRON setzen, schlagen wp-cron.php aus der Crontab des App-Benutzers:

$ su - blog
blog@server:~$ crontab -e

*/5 * * * * /usr/bin/php8.3 /home/blog/htdocs/wp-cron.php >/dev/null 2>&1

Ordnen Sie die PHP-Binärdatei der Version zu, an die Sie übergeben haben app create. Nachher cipi app edit blog --php=8.4, aktualisieren Sie den Crontab-Pfad.

Backups

• cipi db backup blog – Dump MariaDB (planen Sie es jede Nacht in Roots Crontab oder rufen Sie es über Aktionen auf).
• Behalten wp-content/uploads auf dem Server (und in externen Backups). Es ist nicht in Git.
• S3-kompatible Offsite-Backups: cipi backup.

Nützliche Befehle

Häufig gestellte Fragen

Lesen Sie weiter