How to Use CIDI in WordPress

Integrating CI/CD with WordPress might sound overkill—but with CIDI (Continuous Integration & Deployment Infrastructure), it becomes a simple and effective way to:

• Automate plugin/theme updates
• Push content or code live safely
• Eliminate downtime during deployments
• Use Git version control with rollback capability

In this post, we’ll walk through how to connect WordPress to CIDI using GitLab and Docker for automatic deployments.

🧱 What Is CIDI?

CIDI (or Continuous Integration & Deployment Infrastructure) is a lightweight system—typically based on GitLab CI, GitHub Actions, or similar tools—designed to:

• Watch your repo for changes
• Build/test the project
• Deploy it to a remote server (via SSH or Docker)

While CIDI is commonly used in Laravel, Node.js, and static sites, you can absolutely use it with WordPress too.

📦 What You Need

• A GitLab (or GitHub) repository containing:
  • WordPress core (optional, but useful for full control)
  • Your theme(s) or plugin(s)
  • Any custom configs (.htaccess, wp-config.php)
• A server with:
  • Docker or bare-metal PHP stack
  • SSH access
• GitLab CI/CD runner (or self-hosted runner)
• Optional: Docker Compose for portability

📁 Typical Project Structure

wordpress-project/
├── docker-compose.yml
├── wp-content/
│   ├── themes/
│   │   └── your-custom-theme/
│   └── plugins/
│       └── your-plugin/
├── .gitlab-ci.yml
└── wp-config.php

You version-control only what you manage. Core files can be added or excluded based on your workflow.

⚙️ Sample .gitlab-ci.yml for WordPress + CIDI

stages:
  - deploy

before_script:
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - eval $(ssh-agent -s)
  - echo "$DEPLOY_SSH_KEY" | tr -d '\r' | ssh-add -
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
  - ssh-keyscan -H "$DEPLOY_HOST" >> ~/.ssh/known_hosts

deploy:
  stage: deploy
  script:
    - rsync -az --delete ./ "$DEPLOY_USER@$DEPLOY_HOST:/var/www/wordpress-site"
  only:
    - main

This deploys your repo to /var/www/wordpress-site on push to the main branch.

Use Docker if needed:

  script:
    - docker compose down
    - git pull
    - docker compose up -d --build

🔑 GitLab Variables You’ll Need

Set these in your GitLab repo under Settings > CI/CD > Variables:

• DEPLOY_HOST: your server IP (e.g., 123.123.123.123)
• DEPLOY_USER: SSH user (e.g., root or wordpress)
• DEPLOY_SSH_KEY: private key with access

Make sure the public key is added to ~/.ssh/authorized_keys on the server.

🐳 Optional: Use Docker for Isolation

If you manage multiple WordPress sites, Docker is ideal. Sample docker-compose.yml:

version: '3.8'
services:
  wordpress:
    image: wordpress:php8.2-apache
    volumes:
      - ./wp-content:/var/www/html/wp-content
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wp_db
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: secret
    ports:
      - "8080:80"
  db:
    image: mariadb
    restart: always
    environment:
      MYSQL_DATABASE: wp_db
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: secret
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

Push your content to Git → Let CI deploy and spin up containers.

✅ Benefits of Using CIDI with WordPress

• 🛠 Safe deployments (rollback via Git)
• 🚀 Faster release cycle (no FTP, no manual uploads)
• 👀 Full history of theme/plugin/code changes
• 🧪 Integrate tests or linters (e.g., PHPCS or PHPUnit)
• 🔐 No file permission errors (handled during build)

🚫 Things to Avoid

• Don’t version-control the entire wp-content/uploads folder (use object storage or ignore large files)
• Don’t deploy over FTP (slow, unsafe, non-repeatable)
• Don’t store .env or sensitive configs in plain text

Use .gitignore wisely:

wp-content/uploads/
.env

🧩 Final Thoughts

WordPress can absolutely play nice with modern DevOps tools like CIDI. You just need to treat your code like any other app—version-controlled, tested, and deployed automatically.

If you’re building custom themes or plugins, this is a must.

Want a boilerplate repo or full GitLab CI/CD template for your use case? Let me know!