Recreating CircleCI Configuration Using GitHub Actions

In 2025, WordPress VIP adopted GitHub Actions as the primary CI/CD workflow tool to modernize long-term operations. The switch reduces overall system complexity and limits the security footprint of maintaining multiple CI/CD tools. Following adoption of GitHub Actions, support for CircleCI was fully deprecated in March 2026.

As part of creating new workflows, WordPress VIP recommends using a CI/CD method that builds code from a working branch and pushes the result into a -built branch. For example, a develop branch would build into develop-built. VIP advises customers to always move code to the -built branches and to never push code directly to the -built branches.

The trickiest part of migration is that CircleCI and GitHub Actions don’t map one-to-one. This post covers what to recreate from existing CircleCI workflows, how to architect your GitHub Actions workflow, platform constraints, and how to migrate.

What to recreate from CircleCI

For establishing new GitHub Actions workflows, focus on creating the outcomes you want. CircleCI steps don’t need to transfer one for one.

• Branch-based automation maintains your CircleCI operational models. A working branch receives source code changes. A built branch is used for deployment.
• GitHub Actions perform your build logic. This includes common tasks like optimizing static resources, bundling CSS and JavaScript, and using Composer to install dependencies.
• Add ignored files to a .deployignore file, which pushes to -built branches. Unlike .gitignore, this won’t exclude them from deployment.

Recommended GitHub Actions architecture on VIP

You don’t have to start from scratch to set up GitHub Actions. CopyWordPress VIP’s sample workflow directly into your environment and customize it to meet your needs.

Most migrations follow this structure:

• Trigger on pull requests and merge targets so jobs run only when needed.
• Limit workflows to tasks related to the VIP application.
• Install dependencies and build the application using the same commands currently used in CircleCI.
• Push built output to the -built branch using VIP’s build-and-deploy model.
• Use the VIP Dashboard to monitor deployments and troubleshoot build logs.

For authentication setup, refer to the VIP sample workflow, which shows how to use secrets. GITHUB_TOKEN via GITHUB_AUTH_TOKEN.

Common CircleCI migration pitfalls

The most common migration issue we see is incomplete step parity. For example, missing build commands, incorrect file paths, or mismatched theme or plugin references compared with the original CircleCI configuration. Only after GitHub Actions is producing the same deployable output should teams refactor for speed, modularity, or maintainability.

Operational guardrails and platform constraints

GitHub Actions on WordPress VIP runs as a shared service with a few constraints: Only standard-class Linux runners are supported. Keep jobs specific to VIP and only run when necessary. Optimize jobs where possible. VIP may contact you if usage is excessive.

Migration path for WordPress VIP customers

A phased migration approach reduces risk of partial migration, avoids duplicate automation, and keeps your team clear on what’s running.

Phase 1: Inventory the current CircleCI pipeline

Document every build, test, packaging, and deploy step in .circleci/config.yml.

Phase 2: Create the GitHub Actions workflow

Use the WordPress VIP sample workflow to map all documented CircleCI steps into GitHub Actions.

Phase 3: Validate on a non-production branch

Validate new workflows using a non-production branch like develop. Promote to production only after the workflow is confirmed to work as intended.

Phase 4: Cut over completely

Once all GitHub Actions are verified, remove .circleci/config.yml and disable CircleCI. One repository, one deployment path.

Update your deployment process

CircleCI is no longer a supported CI/CD workflow tool. Keep your deployment process intact by moving over to GitHub Actions.

• Build from the working branch.
• Push deployable output to the matching -built branch.
• WordPress VIP deploys from the -built branch.

The hard part is preserving exact build parity and making platform-specific decisions deliberately. The new YAML syntax is the easy bit.