# Git Updater: automatic updates for WordPress plugins and themes hosted on GitHub

> Git Updater is a WordPress plugin that reads a repository URI from a plugin or theme header and turns that repository into an update source. It covers the header format, the API add-ons, the licence gate on authenticated requests, and where it is the wrong tool.

**afragen/git-updater** — This WP plugin will update GitHub, Bitbucket, GitLab, and Gitea hosted plugins and themes

- Repository: https://github.com/afragen/git-updater
- Website: https://git-updater.com
- Stars: 3,321 · Forks: 461
- Language: PHP
- License: GPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/afragen-git-updater

## The problem Git Updater solves for WordPress developers

WordPress has an update system, and it only knows about plugins and themes that arrive through WordPress.org or through a zip file you upload yourself. A development team that keeps its plugin in a GitHub repository has to either push a zip to a server on every release or leave the site running an old copy. Git Updater closes that gap by registering a repository as an update source inside WordPress itself. The README describes it as "a simple plugin to enable automatic updates to your GitHub hosted WordPress plugins, themes, and language packs." The audience is narrow and specific: people who maintain WordPress plugins or themes in version control and want the standard WordPress update screen to do the work. It is not a deployment tool for arbitrary code, and it does not manage a site's content.

## How the repository header drives the update mechanism

The mechanism starts with a header line inside the plugin or theme being updated. For a theme, the header goes in style.css; for a plugin, in the plugin file's header. The README gives the format as GitHub Plugin URI: https://github.com/afragen/git-updater, or GitHub Theme URI: https://github.com/afragen/test-child. The URI must point at owner/repository, and the README states explicitly that you should not include extensions like .git. From that line, Git Updater knows where to look. It then queries the hosting API for release information and language packs, and hands the result to WordPress's update machinery, so the plugin or theme appears in the normal update list rather than in a separate dashboard. The default branch in the repository is develop, which matters for anyone reading the source: the stable tag in the readme points at master, and the README's install link goes to the latest release rather than to the branch. Bitbucket, GitLab, Gitea and Gist are not handled by the core plugin. Each has a separate API plugin, installed from the Add-Ons tab, with its own release page on GitHub.

## Installing Git Updater and pointing it at your first repository

The README points to the latest release on GitHub as the install source rather than to the WordPress.org directory. Download the release zip from the releases page and upload it through the WordPress plugin installer, or place the extracted directory under wp-content/plugins. The plugin requires WordPress 5.9 or later and PHP 8.0 or later, per the readme header. Once active, the only configuration you write is the header in the plugin or theme you want updated. For a theme, that line goes near the top of style.css:

```
GitHub Theme URI: https://github.com/afragen/test-child
```

For a plugin, the same idea goes in the plugin header block, using the plugin variant of the key:

```
GitHub Plugin URI: https://github.com/afragen/git-updater
```

After the header is in place on the site, the plugin or theme shows up in the normal WordPress updates list and WordPress offers the update like any other. For Bitbucket, GitLab, Gitea or Gist, install the matching API plugin from the Add-Ons tab first; without it, the core plugin has no route to those hosts. The repository's own development environment is separate from this: package.json defines wp-env-macos scripts such as npm run env:start and npm run test, which spin up a local WordPress environment for contributors rather than for site owners.

## The licence gate on authenticated API requests

This is the constraint most likely to surprise a team. The README describes a licence purchased from the Git Updater Store, an unlimited yearly licence that "allows for authenticated API requests," with an initial free trial period. After the trial period, the README states that Git Updater will not be able to make authenticated API requests. Authenticated requests are what you need when a host applies rate limits or when a repository is private. A public repository that is queried anonymously may keep working, but the documentation does not promise that, and the README does not document rollback behaviour for any of this. Treat the licence as an operational dependency, not an optional donation: the project also accepts GitHub sponsorship, and the README lists a donate link, but the licence is the item tied to API access. The code itself is GPL-3.0-or-later, so the licence fee is not a copyright restriction on the source; it buys API access and support rather than permission to use the code.

## What Git Updater is not good at

Git Updater updates code that WordPress already knows how to load. It is the wrong tool for deploying a site's configuration, for syncing a database between environments, or for shipping something that is not a plugin, theme or language pack. It also assumes the repository layout matches what WordPress expects: a plugin whose build step produces a zip with a different directory structure than the repository root will not install cleanly, and the README says nothing about build pipelines. Private repositories are the other boundary. Without authenticated requests, a private repository cannot be reached, and the README ties authenticated requests to the paid licence after the trial. Teams that need continuous deployment, atomic releases, or rollback to a previous commit should look elsewhere; Git Updater's unit of work is a WordPress update, not a release. The README also does not document what happens when a repository disappears or a branch is renamed, which is the kind of silence worth noting before you depend on it for client sites.

## Git Updater compared with a deployment tool

Deployer and similar tools take the opposite approach: they run from a control machine or CI job, connect to the server over SSH, and place files there, often with symlinked releases and a rollback command. Git Updater runs inside WordPress and asks the host's API what the latest release is. The difference shows up in what each one can do. A deployment tool can push any file to any path, run migrations, and switch between releases; Git Updater can only update a plugin, theme or language pack that WordPress already loads, and it cannot touch anything outside those directories. In exchange, Git Updater needs no SSH access, no CI configuration and no server credentials, and it works on shared hosting where a deployment pipeline is not an option. WP Pusher occupies a similar space to Git Updater and is named in the searches people run around this project, but its approach is not described in this material, so the honest comparison here is the one against server-side deployment, where the trade is reach against setup cost.

## Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-13. Recent releases listed are 14.4.0 on 2026-08-27, 14.4.1 on 2026-09-01 and 14.4.2 on 2026-09-04, so the release cadence is close together and the version numbers move in patch steps. The default branch is develop while the stable tag in the readme points at master, which is a normal arrangement but means the source you read on the default branch is not necessarily what a site is running. Upgrading Git Updater itself is a normal WordPress plugin update, and the README points at the latest release for that. The ongoing cost is the licence for authenticated API requests plus the API plugins for non-GitHub hosts, which are separate downloads and separate update paths. On the licence side, the plugin ships under GPL-3.0-or-later, which permits redistribution and modification; the paid licence is a service arrangement around API access, and whether that fits your organisation is a question for your own advisers, not something this article can settle.

## Conclusion

Adopt Git Updater if you ship WordPress plugins or themes from a GitHub repository and want WordPress's own update screen to pull from it, and check the header format and the licence status of authenticated API requests before rolling it out to clients. Do not adopt it if your code lives in a private repository that needs authenticated requests and you have no licence or sponsor arrangement, because after the trial period the documentation states Git Updater cannot make authenticated API requests. Verify first that your plugin or theme file carries a GitHub Plugin URI or GitHub Theme URI header pointing at owner/repository with no .git extension, and confirm the current release under the repository's releases page before installing.

## FAQ

### How do I install the Git Updater WordPress plugin?

The README points to the latest release on GitHub rather than the WordPress.org directory. Download that release and install it through the WordPress plugin installer, or extract it under wp-content/plugins. It requires WordPress 5.9 or later and PHP 8.0 or later.

### What header does a plugin or theme need for Git Updater to find it?

A theme needs a GitHub Theme URI header in style.css, and a plugin needs a GitHub Plugin URI header in its plugin header. The URI must point at owner/repository, and the README says not to include extensions like .git.

### Does Git Updater support Bitbucket, GitLab and Gitea?

The core plugin covers GitHub. Bitbucket, GitLab, Gitea and Gist each have a separate API plugin, available for one-click install from the Add-Ons tab and published on their own GitHub release pages.

### Do I need a paid licence for Git Updater?

The README describes an unlimited yearly licence from the Git Updater Store that allows authenticated API requests, with an initial free trial period. After the trial, it states Git Updater will not be able to make authenticated API requests.

### Can Git Updater update a private repository?

The README ties authenticated API requests to the paid licence and says that after the trial period those requests stop. A private repository needs an authenticated request, so the documentation does not describe a way to reach one without that access.

## Sources

- [afragen/git-updater on GitHub](https://github.com/afragen/git-updater)
- [License: GPL-3.0](https://github.com/afragen/git-updater/blob/develop/LICENSE)
- [Project website](https://git-updater.com)
- [README](https://github.com/afragen/git-updater/blob/develop/README.md)
- [Releases](https://github.com/afragen/git-updater/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/afragen-git-updater