Free tools Windows power users keep installed
One-click scans. No signup required.
GitHub does not connect to WordPress through one universal switch. Choose the integration boundary first: use WordPress.com GitHub Deployments for a managed site, GitHub Actions with SSH or rsync for a self-hosted installation, the WordPress.org deployment action for public plugin releases, or the WordPress REST API when the workflow needs to move content and metadata rather than files. Keep credentials in encrypted GitHub secrets, restrict which branches and tags can deploy, and make staging the normal destination before production.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Choose the integration that matches what you are moving
“Integrate GitHub with WordPress” can mean four different jobs. A theme or plugin deployment copies files to a WordPress installation. A WordPress.org release publishes a tagged plugin package to the public plugin repository. A REST API workflow creates or edits WordPress data. WordPress.com GitHub Deployments is a managed hosting feature that connects a repository to a site without requiring you to administer an SSH server.
As an Amazon Associate I earn from qualifying purchases.
| Integration | Best for | Typical trigger | Authentication | Infrastructure control |
|---|---|---|---|---|
| WordPress.com GitHub Deployments | A complete site, theme, or plugin on a managed WordPress.com site | Manual production release or automatic staging release | WordPress.com repository connection | Lowest; the host runs deployment |
| GitHub Actions to self-hosted WordPress | Theme and plugin code on a server you control | Push, pull-request merge, tag, or manual dispatch | SSH key, rsync, or a Deployer-based action | Highest; you control paths and servers |
| WordPress.org plugin deployment | Publishing a public plugin release | Release or Git tag | SVN_USERNAME and SVN_PASSWORD secrets |
Limited to the public plugin repository package |
| WordPress REST API from Actions | Posts, pages, custom data, metadata, and custom endpoints | Build completion, schedule, push, or manual run | Application password or another site-specific token | Data-level control rather than filesystem access |
Do not use a REST API request to replace a code deployment, and do not publish a private server release to WordPress.org. They have different destinations, credentials, rollback methods, and review requirements.
Connect a repository to WordPress.com
WordPress.com documents GitHub Deployments for connecting a plugin, theme, or complete site repository, configuring the deployment, and running the first deployment either manually or automatically. The feature is available on Business and Commerce plans. Free, Personal, and Premium sites must upgrade before the feature can be used.
#1 Best Overall
Recommended production and staging policy
For a production site, choose a manual deployment so a reviewed commit is promoted deliberately. For a staging site, choose automatic deployment so approved changes can be exercised as soon as they reach the selected branch. WordPress.com’s guidance states: “For convenience and maximum control over your production site, we recommend setting up: Manual deployments for production sites. Automatic deployments for staging sites.”
Setup sequence
- Put the theme, plugin, or full site code in a GitHub repository. Remove local configuration and any credentials before the first push.
- In the WordPress.com site’s GitHub deployment settings, connect the repository and select the branch or release source that should be deployed.
- Define the deployment target and whether the first run is manual or automatic. Use a staging site for continuous delivery.
- Run the initial deployment manually and inspect the site before enabling an automatic trigger.
- Promote a tested commit to production through the manual control. Record the commit or tag associated with the release so a rollback can return to a known revision.
This model removes server administration, but it also gives you less control over filesystem-level behavior than an SSH workflow. Treat the repository branch selected in the WordPress.com settings as a production control, and protect it in GitHub.
Recommended Free Tools
Deploy to self-hosted WordPress with GitHub Actions
When you control the web server, a GitHub Actions workflow can check out a commit and transfer only the required files over SSH and rsync. The rtCamp Deploy WordPress action uses Deployer.org and documents a configuration based on .github/workflows/deploy.yml, an encrypted SSH_PRIVATE_KEY secret, and .github/hosts.yml branch mappings. Only branches mapped in that host configuration are eligible to deploy.
Prepare the server and repository
- Create a deployment account that can write the WordPress code directory but does not have unnecessary administrative privileges.
- Install the server-side prerequisites required by your chosen Deployer or rsync method.
- Add the workflow and host configuration under
.github/. - Keep uploads, cache directories, and other runtime-generated data outside the code package unless your backup and dependency strategy explicitly requires them.
- Decide whether you are deploying the whole repository, one theme, or one plugin. A smaller scope reduces accidental changes.
Store the SSH key as a secret
In the repository’s GitHub settings, add the private key as an encrypted secret named SSH_PRIVATE_KEY (or the exact name required by your action). Never commit the private key, a password-protected key’s passphrase, or a production wp-config.php file. Use a deploy-only key and restrict its server account.
Illustrative rsync workflow
The following pattern shows the moving parts without tying your repository to a particular marketplace action. Replace the secret names and remote path with values for your server.
name: Deploy WordPress
on:
push:
branches: [main]
workflow_dispatch:
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Check out the selected commit
uses: actions/checkout@v4
- name: Install SSH key
shell: bash
run: |
install -m 700 -d ~/.ssh
printf '%sn' "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
- name: Transfer code
shell: bash
run: |
rsync -az --exclude='.git' --exclude='wp-content/uploads/' ./
"${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}:${{ secrets.REMOTE_PATH }}"Do not copy this example unchanged into production. The --delete option, if you add it, can remove files on the server; use it only when the remote directory is a deliberately managed release directory. Add excludes for development configuration, tests, local dependency caches, and any server-owned files. Pinning the server’s host key instead of accepting an unknown key at runtime prevents a workflow from silently connecting to the wrong host.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsUsing Deployer and branch maps
A Deployer-based action is useful when you need releases, shared directories, or server-side tasks rather than a simple file copy. In the documented rtCamp setup, the workflow lives in .github/workflows/deploy.yml, the SSH key is supplied through SSH_PRIVATE_KEY, and .github/hosts.yml maps allowed branches to hosts. Map only the branches that should deploy; leaving a branch unmapped is an intentional safety control.
Deploying only a theme or plugin
An alternative marketplace action can deploy directly to Pressable or WP Engine using an SSH private key and rsync. It supports deploying the repository root or selecting a theme or plugin directory through SRC_PATH and REMOTE_PATH. Use a narrow source path when the repository contains documentation, tests, or multiple independent components. Confirm that the remote path is the active theme or plugin directory for the target site before the first run.
Publish a plugin to WordPress.org from a Git tag
Publishing a plugin to WordPress.org is a release-publication workflow, not a deployment to your private production server. The 10up WordPress Plugin Deploy action takes the contents of a Git tag and commits them to the WordPress.org plugin repository using the same tag name.
Prepare the release package
- Choose a release tag that matches the version you intend to publish.
- Use
.distignoreor.gitattributeswithexport-ignorerules to omit tests, development configuration, local tooling, and other files that should not ship. - If the plugin requires a build step, configure the action’s optional build directory or build process so compiled assets exist before the package is committed.
- Keep WordPress.org assets and readme files deliberate; they are part of the public release surface.
Configure credentials and trigger
Add encrypted repository secrets named SVN_USERNAME and SVN_PASSWORD. Configure the 10up action in a workflow triggered by a release or a tag, and require review before tags can be created. A tag-triggered workflow should publish only the tag that initiated the run, not whatever happens to be on the default branch later.
Test the package locally or in staging before creating the public tag. Once the tag is published, users may receive the release through the WordPress.org update system, so changing the tag contents after publication can create confusing, unreproducible builds.
Use the WordPress REST API from GitHub Actions
The WordPress REST API moves data rather than files. The WordPress Plugin Handbook defines the core method semantics: GET retrieves data, POST creates resources, PUT updates them, and DELETE removes them. A workflow can publish structured content after a build, update metadata, synchronize a catalog, or call a custom endpoint supplied by a plugin.
Authentication choices
There is no single authentication scheme that fits every site. A server-side workflow commonly uses an application password over HTTPS, while a custom plugin endpoint may require a site-specific token or another signed request. Design the credential for the endpoint and give it the least privilege required. Do not put a password in a workflow file or pass it as a command-line argument that could appear in logs.
Example: create a post after a build
Store the site base URL, WordPress user, and application password as encrypted secrets such as WP_BASE_URL, WP_USER, and WP_APP_PASSWORD. A shell step can then send JSON to the posts endpoint:
curl --fail-with-body --request POST
--user "${{ secrets.WP_USER }}:${{ secrets.WP_APP_PASSWORD }}"
--header 'Content-Type: application/json'
--data '{"title":"Build complete","status":"draft","content":"Automated release notes"}'
"${{ secrets.WP_BASE_URL }}/wp-json/wp/v2/posts"Start with status set to draft while you validate formatting and permissions. Check the HTTP response and fail the job on errors; a green workflow that silently received a permission or validation error is not a successful publication.
Idempotency and deletion safeguards
Before creating records on every run, decide how the workflow identifies an existing item. A stable slug, an external ID stored in post metadata, or a custom endpoint can prevent duplicate content. Treat PUT and especially DELETE as destructive operations: require a deliberate manual trigger or an environment approval when the workflow can alter production data.
Understand GitHub deployment events and statuses
GitHub’s deployment API models a deployment request for a branch, commit SHA, or tag. A deployment can report queued, in_progress, success, failure, error, or cancelled, with a description and log URL.
Creating a deployment event does not give GitHub access to your WordPress server. GitHub dispatches the event; an external integration, workflow runner, webhook receiver, or deployment action performs the actual work. This separation is why a complete design needs both repository configuration and something that can authenticate to the host or API.
Build safe branch, staging, and rollback controls
Use separate promotion paths
A practical policy is automatic deployment from the main development branch to staging, followed by a reviewed manual promotion to production. For public plugins, use a reviewed release tag instead of deploying every push. For REST API content, use a manual approval whenever the workflow changes published or deletes existing data.
Protect the deployment source
- Require pull-request review and passing checks on branches that can deploy.
- Restrict who can create release tags.
- Map only intended branches in a Deployer host configuration.
- Use GitHub environments for production approvals and environment-specific secrets.
- Log the commit SHA, tag, destination, and result for every run.
Plan the rollback before the first release
A code rollback should redeploy a previously tested commit or tag. Keep database migrations backward-compatible where possible; reverting files does not automatically revert database changes or content created through the REST API. For WordPress.org releases, maintain a known-good package and understand the repository’s release process before attempting to correct a faulty public version.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Exclude files that should never be deployed
Use the ignore mechanism supported by your deployment method. For a WordPress.org package, use .distignore or export-ignore entries in .gitattributes. For SSH or rsync, use explicit excludes. Typical exclusions include:
.git/and repository metadata- Local environment files and development credentials
- Tests, fixtures, and build caches that are not runtime dependencies
- Editor settings and operating-system files
- WordPress uploads and generated cache data, unless intentionally versioned and backed up
Do not exclude a compiled asset merely because it is generated: if the production site needs it and the server does not build it, generate it in the workflow and include the resulting directory.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Troubleshoot the common failure modes
The workflow runs but the site is unchanged
Confirm that the workflow checked out the intended branch or tag, that the source path contains the active theme or plugin, and that the remote path is correct. Check the deployment log for a successful SSH connection and a non-empty rsync transfer. A repository root copied into the wrong WordPress directory can complete without an error while changing nothing visible.
SSH authentication fails
Verify that the public key is installed for the remote deployment user, the secret contains the complete private key including its header and footer, and the file permissions created by the workflow are restrictive. Check the server’s SSH username, port, and host-key configuration. Do not solve the problem by committing the key or disabling host verification globally.
A branch is not eligible to deploy
With the documented Deployer setup, only branches mapped in .github/hosts.yml deploy. Add the branch deliberately, then protect it in GitHub. If the workflow uses a branch filter, confirm that the event name and branch pattern match the push or tag you created.
The plugin package contains unwanted files
Inspect the exported archive before publishing. Add rules to .distignore or .gitattributes, and verify that the build step places compiled files in the directory the release action packages. Never assume that a file ignored by Git is automatically excluded from a WordPress.org export.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The REST API returns 401, 403, or 4xx errors
A 401 usually indicates missing or invalid credentials; a 403 commonly means the authenticated account lacks the required capability. A validation error can indicate malformed JSON, an invalid status, or a field that the endpoint does not accept. Print the response body in the job log only after removing tokens and passwords, and test the same request against staging.
Security checklist before enabling automation
- Store SSH, SVN, and API credentials only in encrypted GitHub secrets or protected environments.
- Use separate credentials for staging and production.
- Limit deployment accounts and API users to the capabilities they need.
- Require reviews for production branches and release tags.
- Deploy to staging first; keep production promotion manual unless the risk is understood and accepted.
- Exclude development files, credentials, tests, and runtime uploads from code packages where appropriate.
- Record deployment statuses and logs, including the commit or tag and destination.
- Back up the database and uploads independently of the Git repository.
- Test rollback of both code and data workflows before relying on automation.
Which architecture should you choose?
Choose WordPress.com GitHub Deployments when you want managed infrastructure and your site is on an eligible Business or Commerce plan. Choose SSH, rsync, or Deployer when you control the server and need precise paths, release directories, or custom deployment tasks. Choose the 10up action when the destination is the public WordPress.org plugin repository and the source of truth is a reviewed Git tag. Choose the REST API when the workflow needs to create or update WordPress data without copying PHP, JavaScript, CSS, or media files.
In every model, keep the repository as the auditable source of code, make staging the default proving ground, and make the deployment target explicit. That separation prevents a content synchronization job from becoming an accidental code release and prevents a production deployment from being triggered by an unreviewed commit.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
