GitHub Actions deploy

What it is

GitHub Actions is a workflow automation service built into GitHub. You write a YAML file describing "when this event happens, run these steps," GitHub runs them on its servers for you. Free for public repos and generous quotas for private ones.

For us, "this event" is a push to a release branch. The steps copy the version-controlled portions of the site (our theme and plugin) onto the server and optionally clear the cache. The whole thing runs well under a minute.

How we use it

Two pipelines, staging and production

Each project gets two parallel pipelines: one wired to the staging branch, one wired to the production branch. Push to staging, the staging site updates. Promote staging to production, the production site updates. Same mechanism for both, different credentials, fully separated.

What deploys, what doesn't

The pipeline only touches the things tracked in git: our custom theme, our custom plugin, and a small set of design assets. Everything else (WordPress core, third-party plugins, the database, server config, secrets) lives on the server and is managed there.

This boundary matters: a deploy cannot break your database. The worst case is a broken template file, which we catch on staging before it touches prod. Bad deploys roll back with one git command.

Production cannot be ahead of staging

The promotion rule is enforced in git: production is only ever a fast-forward of staging. If something is on production, it has been on staging. No direct pushes to production, no emergency "let me just edit it on the live site" moments, no surprise drift between the two environments.

Secrets stay in the CI provider

Deploy credentials never live in the repo. The pipeline asks GitHub for the secret at runtime, GitHub hands it over to the running job, the job uses it once and forgets it. Rotation is straightforward when a key needs to roll. We rotate on a schedule, and any time a contractor stops working on a project.

Fast enough that nobody bypasses it

Each deploy runs in well under a minute. That matters: when the official path is fast and reliable, nobody is tempted to shortcut around it with SFTP. The slow, scary deploy is the one people work around. The boring 40-second deploy is the one that gets used every time.

What you get

• Every change to your site is in git. Full history, full ability to roll back to any prior version with one command.
• Staging first, always. You see every change on staging before it touches production.
• No FTP clients, no "let me upload that file real quick," no .DS_Store files in production.
• Deploys finish in well under a minute. The cost of shipping a small change is small, so we ship more small changes.
• Free. GitHub Actions free tier covers more deploys than any sane WordPress site needs.
• Secrets stay in GitHub. No credentials in your repo, no shared FTP logins floating around.

Where we don't use it

For non-developer clients who want to update their own site via cPanel or SFTP, this pipeline is overkill. Not relevant. (Though we'd push back on that workflow on principle.)

For very high-traffic sites where deploys need to be coordinated with cache warming plus traffic shifting (zero-downtime deploys at meaningful scale), GitHub Actions is the wrong tool. We'd reach for Buddy, GitLab CI, or a custom blue-green setup. GitHub Actions is the right tool for the 99% case, not the 1% case.

For sites running on shared hosting where SSH access is unavailable, this whole pattern doesn't work. That's a hosting problem, not a deploy problem, and the answer is to move off shared hosting.