CI/CD: Goodbye FTP, Hello GitHub Actions

This is part of a series on the modern web stack, written from a WordPress developer’s seat for people who’ve built on the web for years and still hit stack terms they can’t define. The goal is literacy, enough that you can read any stack list and know what each piece does.

Each post has a 10-15 minute audio companion, generated with NotebookLM, for the gym or the commute.

Most WordPress shops still deploy the way they did in 2005. You connect with FileZilla or scp, upload the changed files and hope they’re the right ones. You SSH in and run wp cache flush. You realize you forgot a file, upload it, and wait for a client to call about the bug you introduced.

WordPress never solved this, because the platform grew up when “deploy” meant “copy files to a server.” In a modern stack you write code, commit it to git, push to a branch, and a pipeline does the rest: tests, the production build, a staging deploy, smoke tests, the production deploy, and a notification when each step passes or fails. The name for this is CI/CD, continuous integration and continuous deployment.

This post covers what CI/CD is, what GitHub Actions does, and what changes the day you wire up your first pipeline. If you’ve read the Docker post, the fresh environment each run starts in will look familiar.

What CI/CD Means

CI/CD is two related ideas bolted together.

Continuous integration means merging code into a shared branch often, with automated checks on every change: tests, type-checking, linting, build verification. Anything that catches a broken change before a human reviews it belongs here. The aim is a main branch that’s always deployable.

Continuous deployment automates the release itself. When code lands on main, the pipeline ships it to production with no manual step. Continuous delivery is the same thing with an explicit approval gate before production.

A typical pipeline runs on every push to a branch:

1. Check out the code
2. Install dependencies
3. Run the type-checker
4. Run the linter
5. Run unit tests
6. Build the production bundle
7. Run integration tests against the build
8. If on main, deploy to production
9. Notify Slack or Discord of success or failure

Each step is defined in a YAML file in the repo. The CI service reads the file, spins up a fresh environment and runs the steps in order. If a step fails, the pipeline stops and reports it. That’s the mechanism behind “deploy by git push.”

The WordPress Analogue

GitHub Actions is to your code what cron jobs are to your server, except the jobs fire on events you choose and run somewhere off your infrastructure.

WordPress has nothing like this by default. Even managed hosts like Kinsta and WP Engine build their deployment flows around git pushes to their own systems, not around a pipeline you control. If you’re weighing hosts, hosting beyond Kinsta covers the alternatives.

With CI/CD, the deployment is code, versioned with the rest of the project and reviewable in pull requests. A new team member reads the pipeline file and knows how the project ships. You no longer have to remember which folder to FTP into.

The CI/CD Services to Know

The main services in 2026:

For most WordPress veterans moving to the modern stack, GitHub Actions is the pick. Almost every modern project already lives on GitHub, the marketplace covers the common cases, and the YAML is well documented. It also pairs with the setup in Next.js, the WordPress of React.

A minimal workflow lives at .github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'
      - uses: pnpm/action-setup@v3
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - run: pnpm typecheck
      - run: pnpm test
      - run: pnpm build
      - name: Deploy to Vercel
        run: pnpm dlx vercel deploy --prod --token ${{ secrets.VERCEL_TOKEN }}

On every push to main this installs dependencies with pnpm, type-checks, tests, builds and deploys. secrets.VERCEL_TOKEN lives in GitHub’s secret manager, so the token never appears in the repo.

On Vercel, Netlify and Cloudflare Pages you can often skip the explicit deploy step, because those platforms watch your repo and deploy on their own. You still run CI to gate the deploy on passing tests.

What This Changes for WordPress People

Three practical wins come with the first pipeline.

No more “did I upload that file”

Once the pipeline owns deployment, the only question is whether the code is on main. If it is, it’s deployed. You stop tracking what state the production server is in.

Preview deploys per pull request

Vercel and Netlify give every PR a unique URL, deployed from the PR branch. Clients review changes on a real URL before merge. For client work that means sending links instead of emailing screenshots.

Tests that get written

WordPress culture has historically had thin test coverage because tests had no consistent place to run. With CI, they run on every push, feedback is immediate, and you write more of them.

You can wire CI/CD into a WordPress project even if you stay on Kinsta or WP Engine. Run linting, PHPStan and unit tests on every push, build a production-ready ZIP, and deploy through the host’s API or SSH. The pipeline shape is the same, and only the deploy target changes.

Secrets, Caches, and Other Traps

Secrets management

Never commit API keys, database credentials or tokens to git. Use the CI service’s secret store and rotate secrets when team members leave. If a secret lands in the repo by accident, treat it as compromised and rotate it right away, because git history makes secrets hard to remove.

Slow pipelines

A 15-minute pipeline is barely useful. Aim for 3-5 minutes on a typical project: cache dependencies and run independent jobs in parallel. The faster the feedback, the more the pipeline gets used.

Flaky tests

A pipeline that fails 20% of the time for reasons unrelated to your change teaches the team to ignore failures. Fix or remove flaky tests quickly. A reliable red light beats an unreliable amber one.

Deploy gates

Deploying to production on every push to main works when main is rarely broken. Larger teams are usually safer with an approval step before production. The right choice depends on team size and how mature your tests are.

Cost

GitHub’s free minutes are generous, but private-repo minutes add up. A badly configured workflow that runs 30 minutes on every push to every branch burns through the quota fast, so check usage after adding new jobs.

Level Up Your CI/CD

Video

• “GitHub Actions in 100 Seconds” by Fireship, then “GitHub Actions for Beginners” by TechWorld with Nana (about 30 minutes).
• “CI/CD Explained” by Codedamn or similar. Search for one with at least 100k views, since the topic is well covered.

Docs worth bookmarking

• The GitHub Actions docs. The Quickstart and “Understanding workflows” pages cover most of what you need, and the marketplace is where pre-built actions live.
• Reusable workflows, for sharing workflow logic once you have more than two projects.
• The 12-factor app. It isn’t CI-specific, but its principles on environment variables, dependencies and process model shape good CI/CD practice.

The next post covers observability: what replaces SSH-ing in to tail -f error_log when the production server isn’t somewhere you can log into.

Related

Self-Hosting Apps on a Small VPS: A Plain-English Setup Guide

How the Pieces Wire Up: A Modern Stack Integration Tour

BatchPilot: Bulk Edit and Delete WordPress Content

Verdix Reviews

Local WP vs Docker: When to Use Each for WordPress Development

How to Remove DRM from Amazon Books