Déployez WordPress sur Cipi : application personnalisée & GitHub déploiement automatique

Par Andrea Pollastri · Dernière mise à jour : 22 août 2026 · lecture gratuite, pas de paywall

Cipi est Laravel-premier, mais il héberge également WordPress en tant que application personnalisée: utilisateur Linux isolé, pool PHP-FPM, Nginx vhost, Git pull into htdocs. Ce guide part d'un Ubuntu VPS vide jusqu'à un site qui se déploie à chaque poussée pour main.

Pourquoi une application personnalisée (pas Laravel)

Cipi prend en charge deux types d'applications. La valeur par défaut est Laravel : propre utilisateur du système, PHP-FPM ou Octane, MariaDB, .env, Supervisor travailleurs, crontab et zéro temps d'arrêt Versions du déployeur sous current/shared. WordPress n’est rien de tout cela.

A application personnalisée (cipi app create --custom) est la bonne forme :

• Déploiement classique dans htdocs — non current/shared échange de lien symbolique. cipi deploy blog extrait le dépôt dans /home/blog/htdocs.
• Nginx est déjà prêt pour WordPress : index index.html index.php et try_files $uri $uri/ /index.php?$args.
• Git est facultatif. Ignorez le référentiel pour les téléchargements SFTP uniquement ; attachez-en un plus tard avec cipi app edit blog --repository=….
• Pas de base de données, non .env, pas de cron, pas de files d'attente jusqu'à ce que vous les ajoutiez. WordPress a besoin d'une base de données — vous la créez à l'étape suivante.

Comment structurer le dépôt WordPress

Considérez Git comme la source de vérité pour coder, pas pour les secrets ou les médias. Un dépôt qui survit au déploiement automatique ressemble à ceci :

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
  …

Mets ça dedans .gitignore donc un pull n'écrase jamais l'état du site en direct :

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

Parce que les applications personnalisées s'intègrent htdocs au lieu d'échanger un répertoire de version, les fichiers non suivis restent sur le disque. C'est ainsi que les téléchargements et wp-config.php survivre à chaque déploiement.

• Noyau dans Gitest le workflow d'agence le plus simple : le thème, les plugins et WordPress lui-même sont versionnés ensemble.
• Composer / Bedrock fonctionne aussi - réglé --docroot=web (ou public) lorsque le contrôleur frontal n'est pas à la racine du dépôt.
• Ne commettez pas de secrets de production. Générer des sels sur le serveur ; ne pousse jamais un live wp-config.php.

Créer l'application personnalisée

Cipi doit déjà être installé sur un nouveau Ubuntu VPS :

SSH en tant que cipi, alors sudo -s. Créez l'application WordPress de manière non interactive (PHP 8.3 est une correspondance sûre pour l'actuelle WordPress ; échangez-la à chaud ultérieurement avec 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

Ces dispositions :

• Utilisateur Linux blog et à la maison /home/blog
• Pool PHP-FPM sur 8.3 et un vhost Nginx pour blog.example.com
• Clé de déploiement SSH pour le référentiel
• Configuration du déployeur qui s'intègre /home/blog/htdocs

Si vous avez d'abord enregistré un jeton d'accès personnel GitHub, Cipi ajoute également automatiquement la clé de déploiement et un fournisseur webhook :

$ cipi git github-token ghp_xxxxxxxxxxxxxxxxxxxx
$ cipi git status

Besoin de jetons à grain fin Administration et Webhooks réglé sur Lire et écrire sur le repo cible ; les jetons classiques ont besoin du repo portée. Les détails sont dans le Configuration automatique de Git documents.

SFTP uniquement (pas encore de Git) — omettez le référentiel et téléchargez-le dans ~/htdocs en tant qu'utilisateur de l'application :

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

Base de données, DNS et SSL

Les applications personnalisées ne disposent pas de base de données. Créez-en un après que l'application existe — MariaDB est la valeur par défaut et ce que WordPress attend :

$ cipi db create --name=blog

Cipi imprime le nom de la base de données, l'utilisateur, le mot de passe et un mariadb+ssh:// URL pour TablePlus ou DBeaver. Copiez ces valeurs ; ils entrent dans wp-config.php sur le serveur, pas dans Git.

Point DNS A enregistrements pour blog.example.com et www.blog.example.com au VPS, alors :

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

cipi ssl install émet un certificat Let's Encrypt qui couvre chaque alias (SAN) et active la redirection HTTPS. cipi www garde l'apex et www canoniques. Voir SSL et redirections www.

Déployez d'abord et wp-config.php

Extrayez le référentiel une fois, puis écrivez la configuration en tant qu'utilisateur de l'application afin que la propriété du fichier reste correcte :

$ 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

Valeurs de production minimales (utilisez les informations d'identification de 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');

Générer de nouveaux sels à partir de api.wordpress.org/secret-key et collez-les à la place des espaces réservés. Ouvert https://blog.example.com et terminez le programme d'installation WordPress dans le navigateur.

GitHub Pipeline d'actions (recommandé)

L'Agent Laravel webhook (https://your-app.com/cipi/webhook) est un itinéraire à l'intérieur une application Laravel. Il n'existe pas sur WordPress. Pour le déploiement automatique, connectez GitHub SSH au serveur et exécutez cipi deploy — pareil Déploiement SSH du pipeline Cipi documents pour les versions fermées Laravel.

Choisissez un déclencheur. Si la configuration automatique de Git a déjà créé un fournisseur webhook, désactivez-le (ou n'en créez jamais) avant d'ajouter des actions. Deux déploiements sur le même combat push pour le fichier de verrouillage.

1. Clé SSH dédiée pour CI

Générez une clé ed25519 sur votre ordinateur portable. Ajoutez le publique clé du serveur ; stocker le privé clé comme secret GitHub. Ne réutilisez pas les clés de déploiement Git ou votre clé SSH personnelle.

# 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

Dans le dépôt GitHub : Paramètres → Secrets et variables → Actions. Créer :

• SERVER_HOST — VPS IP ou nom d'hôte
• SERVER_SSH_KEY — le contenu complet de la clé privée

2. Fichier de flux de travail

Déposez ceci .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

Ce que cela vous rapporte :

• Un portail de qualité — un engagé wp-config.php ou une erreur d'analyse PHP n'atteint jamais le VPS.
• Une commande sur le serveur — Cipi tire main dans htdocs avec le binaire PHP de l’application.
• Relecture manuelle — workflow_dispatch redéploye le même commit sans autre poussée.

Protéger main: pas de poussées directes, vérifications de statut requises, branches de courte durée. Les mêmes habitudes basées sur le tronc que le Guide Laravel CI/CD, sans prétendre que WordPress possède Pest et Pint.

Regardez le déploiement depuis le serveur :

$ cipi app logs blog --type=deploy

3. Facultatif : sauvegarde avant la publication

Les changements de schéma sont souvent irréversibles. Prenez d'abord l'instantané MariaDB, puis déployez :

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

Restaurer avec cipi db restore blog backup.sql.gz si une version tourne mal. Les applications personnalisées n'ont pas de lien symbolique de version vers lequel revenir - le vidage de la base de données est votre bouton d'annulation. Voir cipi dB.

Chemin plus simple : configuration automatique de Git

Si vous n'avez pas besoin de portes CI (site solo, commits de confiance), ignorez les actions et laissez Cipi câbler GitHub pour vous :

$ 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

Sur app create, Cipi ajoute la clé de déploiement SSH et un webhook sur le référentiel. Le résumé montre configuré automatiquement ✓. Une poussée pour main puis fonctionne de la même manière cipi deploy pipeline sans fichier YAML.

Si vous avez créé l'application avant d'enregistrer un token, imprimez les valeurs et ajoutez-les à la main :

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

Cron, sauvegardes et opérations quotidiennes

Remplacez WP-Cron par le système cron

Les applications personnalisées ne reçoivent pas de crontab. Avec DISABLE_WP_CRON fixer, frapper wp-cron.php depuis la crontab de l'utilisateur de l'application :

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

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

Faites correspondre le binaire PHP à la version à laquelle vous avez transmis app create. Après cipi app edit blog --php=8.4, mettez à jour le chemin de la crontab.

Sauvegardes

• cipi db backup blog — dump MariaDB (planifiez-le tous les soirs dans la crontab de root ou appelez-le depuis Actions).
• Garder wp-content/uploads sur le serveur (et dans les sauvegardes hors site). Ce n'est pas dans Git.
• Sauvegardes hors site compatibles S3 : cipi backup.

Commandes utiles

Questions fréquemment posées

Continuez à lire