Git Updater - Git-Hosted Updates for WordPress Plugins and Themes

Git Updater solves a specific WordPress problem: plugins and themes you host yourself get no update notifications, because WordPress only knows how to check wordpress.org. It is GPL-3.0-or-later, at version 14.4.2.4, and it requires WordPress 5.9 and PHP 8.0 or newer.

The mechanism is one line in a file header. The thing to understand before installing it is what that line grants.

How it works, which is simpler than expected

You add a header to your plugin’s main file or your theme’s style.css:

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

or, for a theme:

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

The URI points at the owner/repository — and the README is specific that you “should not include any extensions like .git.”

That is the whole integration. Git Updater then checks that repository for new tags or releases and surfaces updates in the ordinary WordPress updates screen, alongside everything from wordpress.org. Your private plugin behaves like a public one.

GitHub support is built into the plugin itself. Bitbucket, GitLab, Gitea and Gist each require a separate API add-on plugin, installable from the plugin’s own Add-Ons tab. That architecture keeps the core small and is worth knowing before you plan a GitLab-based workflow: you need two plugins, not one.

The thing you are actually installing

Be clear-eyed about this, because it is the real decision. Git Updater is a plugin that fetches code from a remote repository and installs it into your WordPress site automatically.

That is enormous authority. Whoever controls the repository named in that header controls code execution on your site. The failure modes are not theoretical: a compromised GitHub account, a repository transferred to someone else, a typo in the URI pointing at a repository you do not own, or a maintainer who stops paying attention to a repository you still trust.

So the operating rules worth writing down:

Only point it at repositories you control, or at a vendor whose repository you would already trust with your site.
Use a private repository with a token for anything commercial, rather than relying on a public repo’s obscurity.
Audit the headers when you inherit a site. A GitHub Plugin URI you did not add is a supply-chain question, not a curiosity.

None of this is a criticism of the plugin. It is the inherent shape of self-hosted auto-updates, and the alternative — manually uploading ZIP files forever — has its own well-known failure mode, which is that nobody does it.

The changelog is a security story right now

We read CHANGES.md in the repository, and the current [unreleased] section is unusual. A sample of what is in it, quoted from the project’s own entries:

“security: settings save handlers (Settings, Additions/Settings, Lite_Domains) now require manage_options (single-site) or manage_network_options (multisite) in addition to the nonce, so a low-privilege user cannot alter tokens, Additions, or lite-domain settings”

“security: verify the settings nonce and install_plugins/install_themes capability in Install::install() before processing a remote install — closes a CSRF install vector”

“security: require a nonce and manage_options/manage_network_options capability to reset the Remote Management REST API key”

“security: encodeURIComponent() the selected branch/tag before appending it to the rollback href in the theme branch switcher, so a crafted remote branch name cannot inject into the URL”

Plus a fail-closed fix in the cache layer’s column whitelist, which previously “silently” rewrote an unknown column.

Two readings of this, and both are fair. The encouraging one: the maintainer is actively hardening capability and nonce checks across every settings surface, and documenting each fix precisely rather than hiding it in “various improvements.” That is exactly what you want from the maintainer of a plugin with this much authority.

The actionable one: these entries are under [unreleased]. They are in the repository, not in a tagged release. Combined with the README’s “Stable tag: master” pointing at the latest GitHub release, the practical advice is to track releases for this plugin specifically and apply them promptly — and, if you run multisite, to note that several of the fixes concern manage_network_options.

Nothing here suggests a crisis. It suggests a plugin whose permission surface is being systematically tightened, which is worth knowing when you decide how closely to follow its updates.

Who should use it

Anyone shipping a WordPress plugin or theme that will never be on wordpress.org: client work, internal tools, a commercial product with its own distribution, a child theme maintained across several sites. For that audience, Git Updater turns a manual chore into the normal WordPress update flow, and the one-line header means your package needs no build step or custom update server.

It is unnecessary if everything you run comes from wordpress.org, and it is the wrong tool if your deployment is already managed by Composer or a CI pipeline — those solve the same problem further upstream, and stacking an in-dashboard updater on top of them invites the two to disagree about what is installed.

For the broader context of what it means to operate a WordPress site rather than merely build one, our review of WordPress covers the ecosystem’s maintainability problem; if the conclusion you reach is that you would rather not operate a PHP application at all, Astro is the other end of that spectrum.

The finding: the integration really is one header line and the GitHub support is built in, with Bitbucket, GitLab, Gitea and Gist each needing their own add-on plugin. The thing to weigh is not the convenience but the authority — this grants a remote repository the right to install code on your site — and the current [unreleased] changelog is a run of capability and nonce hardening, which makes staying current on this particular plugin more than routine advice.