Implante WordPress em Cipi: aplicativo personalizado & GitHub implantação automática

Por Andrea Pollastri · Última atualização: 22 de agosto de 2026 · grátis para ler, sem acesso pago

Cipi é Laravel-primeiro, mas também hospeda WordPress como um aplicativo personalizado: usuário Linux isolado, pool PHP-FPM, Nginx vhost, Git pull into htdocs. Este guia caminha de um Ubuntu VPS vazio para um site que se implanta a cada push para main.

Por que um aplicativo personalizado (não Laravel)

Cipi suporta dois tipos de aplicativos. O padrão é Laravel: próprio usuário do sistema, PHP-FPM ou Octane, MariaDB, .env, Supervisor trabalhadores, crontab e tempo de inatividade zero Versões do implantador em current/shared. WordPress não é nada disso.

A aplicativo personalizado (cipi app create --custom) tem a forma correta:

• Implantação clássica em htdocs - não current/shared troca de link simbólico. cipi deploy blog puxa o repositório para /home/blog/htdocs.
• Nginx já está WordPress pronto: index index.html index.php e try_files $uri $uri/ /index.php?$args.
• Git é opcional. Ignore o repositório para uploads somente SFTP; anexe um mais tarde com cipi app edit blog --repository=….
• Sem banco de dados, não .env, sem cron, sem filas até você adicioná-los. WordPress precisa de um banco de dados — você o cria na próxima etapa.

Como estruturar o repositório WordPress

Trate o Git como a fonte da verdade para código, não para segredos ou mídia. Um repositório que sobrevive à implantação automática é assim:

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
  …

Coloque isso .gitignore portanto, um pull nunca substitui o estado do site ativo:

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

Como os aplicativos personalizados entram htdocs em vez de trocar um diretório de lançamento, arquivos não rastreados permanecem no disco. É assim que os uploads e wp-config.php sobreviver a cada implantação.

• Núcleo no Gité o fluxo de trabalho mais simples da agência: tema, plugins e o próprio WordPress versionados juntos.
• Composer / Bedrock também funciona - definir --docroot=web (ou public) quando o controlador frontal não está na raiz do repositório.
• Não cometa segredos de produção. Gere sais no servidor; nunca empurre uma live wp-config.php.

Crie o aplicativo personalizado

Cipi já deve estar instalado em um novo Ubuntu VPS:

SSH em como cipi, então sudo -s. Crie o aplicativo WordPress de forma não interativa (PHP 8.3 é uma correspondência segura para o WordPress atual; troque a quente mais tarde com 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

Essas disposições:

• Usuário Linux blog e casa /home/blog
• Pool de PHP-FPM em 8.3 e um vhost de Nginx para blog.example.com
• Chave de implantação SSH para o repositório
• Configuração do implantador que entra /home/blog/htdocs

Se você salvou um token de acesso pessoal GitHub primeiro, Cipi também adiciona a chave de implantação e um provedor webhook automaticamente:

$ cipi git github-token ghp_xxxxxxxxxxxxxxxxxxxx
$ cipi git status

Tokens refinados precisam Administração e Webhooks definido como Ler e escrever no repositório de destino; tokens clássicos precisam do repo escopo. Os detalhes estão no Configuração automática do Git documentos.

Somente SFTP (ainda sem Git) — omita o repositório e faça upload para ~/htdocs como usuário do aplicativo:

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

Banco de dados, DNS e SSL

Os aplicativos personalizados não obtêm um banco de dados. Crie um depois que o aplicativo existir — MariaDB é o padrão e o que WordPress espera:

$ cipi db create --name=blog

Cipi imprime o nome do banco de dados, usuário, senha e um mariadb+ssh:// URL para TablePlus ou DBeaver. Copie esses valores; eles entram wp-config.php no servidor, não no Git.

Ponto DNS A registros para blog.example.com e www.blog.example.com em VPS, então:

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

cipi ssl install emite um certificado Let’s Encrypt que cobre todos os alias (SAN) e ativa o redirecionamento HTTPS. cipi www mantém apex e www canônicos. Veja SSL e redirecionamentos www.

Primeiro implante e wp-config.php

Extraia o repositório uma vez e escreva a configuração como o usuário do aplicativo para que a propriedade do arquivo permaneça correta:

$ 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 produção (use as credenciais 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');

Gere novos sais a partir de api.wordpress.org/secret-key e cole-os no lugar dos espaços reservados. Abrir https://blog.example.com e finalize o instalador WordPress no navegador.

GitHub Pipeline de ações (recomendado)

O Agente Laravel webhook (https://your-app.com/cipi/webhook) é uma rota dentro um aplicativo Laravel. Não existe em WordPress. Para implantação automática, tenha GitHub SSH no servidor e execute cipi deploy - o mesmo implantação de SSH de pipeline Cipi documentos para liberações Laravel fechadas.

Escolha um gatilho. Se a configuração automática do Git já criou um provedor webhook, desative-o (ou nunca crie um) antes de adicionar ações. Duas implantações no mesmo push lutam pelo arquivo de bloqueio.

1. Chave SSH dedicada para CI

Gere uma chave ed25519 em seu laptop. Adicione o público chave para o servidor; armazenar o privado chave como um segredo GitHub. Não reutilize chaves de implantação do Git ou sua chave SSH pessoal.

# 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

No repositório GitHub: Configurações → Segredos e variáveis → Ações. Criar:

• SERVER_HOST — VPS IP ou nome de host
• SERVER_SSH_KEY — conteúdo completo da chave privada

2. Arquivo de fluxo de trabalho

Deixe isso dentro .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

O que isso compra para você:

• Um portão de qualidade - um compromisso wp-config.php ou um erro de análise PHP nunca atinge VPS.
• Um comando no servidor — Cipi puxa main em htdocs com o binário PHP do aplicativo.
• Repetição manual — workflow_dispatch reimplanta o mesmo commit sem outro push.

Proteger main: sem push direto, verificações de status obrigatórias, ramificações de curta duração. Os mesmos hábitos baseados no tronco que os Laravel CI/CD guia, sem fingir que WordPress tem Pest e Pint.

Assista à implantação do servidor:

$ cipi app logs blog --type=deploy

3. Opcional: backup antes do lançamento

WordPress alterações de esquema são muitas vezes irreversíveis. Instantâneo MariaDB primeiro e depois implante:

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

Restaurar com cipi db restore blog backup.sql.gz se um lançamento der errado. Os aplicativos personalizados não têm link simbólico de lançamento para reverter - o despejo do banco de dados é o seu botão de desfazer. Veja cipi db.

Caminho mais simples: configuração automática do Git

Se você não precisa de portas CI (site solo, commits confiáveis), pule as ações e deixe Cipi conectar GitHub para você:

$ 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

Ligado app create, Cipi adiciona a chave de implantação SSH e um webhook no repositório. O resumo mostra configurado automaticamente ✓. Um empurrão para main então executa o mesmo cipi deploy pipeline sem um arquivo YAML.

Se você criou o aplicativo antes de salvar um token, imprima os valores e adicione-os manualmente:

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

Cron, backups e operações diárias

Substitua WP-Cron pelo sistema cron

Aplicativos personalizados não recebem crontab. Com DISABLE_WP_CRON definir, acertar wp-cron.php do crontab do usuário do aplicativo:

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

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

Combine o binário PHP com a versão que você passou para app create. Depois cipi app edit blog --php=8.4, atualize o caminho do crontab.

Cópias de segurança

• cipi db backup blog - dump MariaDB (agende-o todas as noites no crontab do root ou chame-o em Actions).
• Mantenha wp-content/uploads no servidor (e em backups externos). Não está no Git.
• Backups externos compatíveis com S3: cipi backup.

Comandos úteis

Perguntas frequentes

Continue lendo