Implementar WordPress en Cipi: aplicación personalizada & GitHub implementación automática

Por Andrea Pollastri · Última actualización: 22 de agosto de 2026 · lectura gratuita, sin muro de pago

Cipi es Laravel primero, pero también alberga WordPress como aplicación personalizada: usuario aislado de Linux, grupo PHP-FPM, Nginx vhost, Git pull into htdocs. Esta guía camina desde un Ubuntu VPS vacío hasta un sitio que se despliega en cada impulso para main.

Por qué una aplicación personalizada (no Laravel)

Cipi admite dos tipos de aplicaciones. El valor predeterminado es Laravel: usuario propio del sistema, PHP-FPM o Octane, MariaDB, .env, Supervisor trabajadores, crontab y tiempo de inactividad cero Versiones del implementador en current/shared. WordPress no es nada de eso.

A aplicación personalizada (cipi app create --custom) es la forma correcta:

• Implementación clásica en htdocs - no current/shared intercambio de enlaces simbólicos. cipi deploy blog introduce el repositorio en /home/blog/htdocs.
• Nginx ya está WordPress listo: index index.html index.php y try_files $uri $uri/ /index.php?$args.
• Git es opcional. Omita el repositorio para cargas solo mediante SFTP; adjunte uno más tarde con cipi app edit blog --repository=….
• Sin base de datos, no .env, sin cron, sin colas hasta que los agregues. WordPress necesita una base de datos; la crea en el siguiente paso.

Cómo estructurar el repositorio WordPress

Trate a Git como la fuente de verdad para código, no por secretos o medios. Un repositorio que sobrevive a la implementación automática tiene este aspecto:

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
  …

Pon esto en .gitignore por lo que una extracción nunca sobrescribe el estado del sitio activo:

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

Porque las aplicaciones personalizadas entran htdocs en lugar de intercambiar un directorio de lanzamiento, Los archivos sin seguimiento permanecen en el disco.. Así es como se suben y wp-config.php sobrevivir a cada despliegue.

• Núcleo en Gites el flujo de trabajo de agencia más simple: tema, complementos y el propio WordPress versionados juntos.
• Composer / Bedrock también funciona - establecer --docroot=web (o public) cuando el controlador frontal no está en la raíz del repositorio.
• No cometa secretos de producción. Generar sales en el servidor; nunca empujes una vida wp-config.php.

Crea la aplicación personalizada

Cipi ya debe estar instalado en un nuevo Ubuntu VPS:

SSH en como cipi, entonces sudo -s. Cree la aplicación WordPress de forma no interactiva (PHP 8.3 es una combinación segura para la WordPress actual; intercambie en caliente más tarde con 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

Que disposiciones:

• usuario de linux blog y hogar /home/blog
• Grupo PHP-FPM en 8.3 y un vhost Nginx para blog.example.com
• Clave de implementación SSH para el repositorio
• Configuración del implementador que ingresa /home/blog/htdocs

Si primero guardó un token de acceso personal GitHub, Cipi también agrega la clave de implementación y un proveedor webhook automáticamente:

$ cipi git github-token ghp_xxxxxxxxxxxxxxxxxxxx
$ cipi git status

Se necesitan tokens detallados administración y Ganchos web establecer en leer y escribir en el repositorio de destino; Los tokens clásicos necesitan el repo alcance. Los detalles están en el configuración automática de git documentos.

Solo SFTP (aún sin Git): omita el repositorio y cárguelo en ~/htdocs como usuario de la aplicación:

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

Base de datos, DNS y SSL

Las aplicaciones personalizadas no obtienen una base de datos. Cree uno después de que exista la aplicación: MariaDB es el valor predeterminado y lo que WordPress espera:

$ cipi db create --name=blog

Cipi imprime el nombre de la base de datos, el usuario, la contraseña y un mariadb+ssh:// URL para TablePlus o DBeaver. Copie esos valores; ellos entran wp-config.php en el servidor, no en Git.

Punto DNS A registros para blog.example.com y www.blog.example.com en el VPS, entonces:

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

cipi ssl install emite un certificado Let's Encrypt que cubre todos los alias (SAN) y activa la redirección HTTPS. cipi www mantiene apex y www canónicos. Ver SSL y www redirecciones.

Primero implemente y wp-config.php

Extraiga el repositorio una vez, luego escriba la configuración como usuario de la aplicación para que la propiedad del archivo siga siendo correcta:

$ 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

Valores mínimos de producción (use las credenciales 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');

Generar nuevas sales a partir de api.wordpress.org/clave-secreta y péguelos en lugar de los marcadores de posición. Abierto https://blog.example.com y finalice el instalador WordPress en el navegador.

GitHub Acciones en proceso (recomendado)

El Laravel Agente webhook (https://your-app.com/cipi/webhook) es una ruta dentro una aplicación Laravel. No existe en WordPress. Para la implementación automática, tenga GitHub SSH en el servidor y ejecute cipi deploy - lo mismo implementación de canalización SSH Cipi documentos para liberaciones cerradas Laravel.

Elija un desencadenante. Si la configuración automática de Git ya creó un proveedor webhook, desactívelo (o nunca cree uno) antes de agregar Acciones. Dos despliegues en el mismo empujón pelean por el archivo de bloqueo.

1. Clave SSH dedicada para CI

Genere una clave ed25519 en su computadora portátil. Añade el publico clave para el servidor; almacenar el privado clave como un secreto GitHub. No reutilice las claves de implementación de Git ni su clave SSH personal.

# 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

En el repositorio GitHub: Configuración → Secretos y variables → Acciones. Crear:

• SERVER_HOST — VPS IP o nombre de host
• SERVER_SSH_KEY - contenido completo de la clave privada

2. Archivo de flujo de trabajo

Deja esto en .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

Lo que esto te compra:

• Una puerta de calidad - un comprometido wp-config.php o un error de análisis PHP nunca llega al VPS.
• Un comando en el servidor — Cipi tira main en htdocs con el binario PHP de la aplicación.
• repetición manual — workflow_dispatch vuelve a implementar el mismo compromiso sin otro empujón.

proteger main: sin empujones directos, verificaciones de estado requeridas, ramificaciones de corta duración. Los mismos hábitos basados en el tronco que el Laravel CI/CD guía, sin pretender que WordPress tiene Pest y Pint.

Mire la implementación desde el servidor:

$ cipi app logs blog --type=deploy

3. Opcional: copia de seguridad antes del lanzamiento

Los cambios de esquema suelen ser irreversibles. Primero la instantánea MariaDB, luego implemente:

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

Restaurar con cipi db restore blog backup.sql.gz si un lanzamiento sale mal. Las aplicaciones personalizadas no tienen un enlace simbólico de lanzamiento al que retroceder: el volcado de la base de datos es el botón para deshacer. Ver cipi dB.

Ruta más sencilla: configuración automática de Git

Si no necesita puertas de CI (sitio individual, confirmaciones confiables), omita Acciones y deje que Cipi conecte GitHub por usted:

$ 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

encendido app create, Cipi agrega la clave de implementación SSH y un webhook en el repositorio. El resumen muestra configurado automáticamente ✓. un empujón para main luego corre lo mismo cipi deploy canalización sin un archivo YAML.

Si creaste la aplicación antes de guardar un token, imprime los valores y agrégalos a mano:

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

Cron, copias de seguridad y operaciones diarias

Reemplace WP-Cron con el sistema cron

Las aplicaciones personalizadas no obtienen un crontab. con DISABLE_WP_CRON establecer, golpear wp-cron.php desde el crontab del usuario de la aplicación:

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

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

Haga coincidir el binario PHP con la versión que pasó app create. después cipi app edit blog --php=8.4, actualice la ruta del crontab.

Copias de seguridad

• cipi db backup blog — volcar MariaDB (programarlo todas las noches en el crontab de root o llamarlo desde Acciones).
• mantener wp-content/uploads en el servidor (y en copias de seguridad externas). No está en Git.
• Copias de seguridad externas compatibles con S3: cipi backup.

Comandos útiles

Preguntas frecuentes

Sigue leyendo