You've released a new plugin version on GitHub, but users are stuck on the old one. Downloading ZIPs by hand, uploading through the admin panel, checking compatibility: routine tasks that eat up time and breed errors.

The standard WordPress update mechanism is tied to the official WordPress.org directory. But not every plugin ends up there: custom client solutions, internal team tools, forks of popular plugins with modifications. These need a different path.

Fortunately, delivering updates directly from GitHub was solved long ago. Below are two working methods: simple (the Git Updater plugin, a couple of clicks) and advanced (a built-in PHP class for full control).

💡 Quick overview:

• Install Git Updater: it picks up GitHub releases as regular WordPress updates
• For private repositories, configure an access token in the plugin settings
• If you're writing your own plugin and want to embed auto-updates in the code: use the built-in PHP class
• The repository must contain a valid plugin header and version tag

Method 1: Git Updater, two-click updates

Git Updater is a free plugin that adds support for GitHub, Bitbucket, GitLab, and Gitea to the standard WordPress updates screen. After installation, plugins and themes from GitHub update in the same place as regular ones: Dashboard → Updates.

Developer Andy Fragen has maintained the project since 2015. The Git Updater GitHub page has over 400 stars and an active repository with regular commits. The knowledge base at git-updater.com covers installation, token configuration, and API usage.

Installation is simple: download the ZIP from the GitHub release, upload via Plugins → Add New → Upload Plugin, and activate. The plugin immediately starts tracking repositories specified in the headers of installed plugins and themes.

For private repositories, you'll need a token. Create a Personal Access Token in GitHub Settings → Developer settings → Tokens (permissions: repo for private; no token needed for public), paste it into Settings → Git Updater. After that, the plugin can see even closed repositories.

An important detail: Git Updater checks for tags in the X.Y.Z format (semantic versioning) in the repository. If there are no tags, the update won't work. Before releasing, always set a tag: git tag 1.2.0 && git push --tags.

Method 2: built-in PHP class for developers

If you're a plugin author and want to embed the auto-update mechanism directly in your code (without a separate intermediary plugin), the classic PHP class approach still works. It's lighter than the original class from Joachim Kudish and radishconcepts and uses native WordPress hooks.

Add the following code to your plugin's main file or to a separate updater.php file included via require_once:

1
/**
2
 * Auto-update from GitHub releases.
3
 * Place in main plugin file or include via require_once.
4
 */
5
function myplugin_check_github_update($transient) {
6
    if (empty($transient->checked)) {
7
        return $transient;
8
    }
9
 
10
    $plugin_slug = 'my-plugin/my-plugin.php';
11
    $github_repo = 'username/my-plugin';
12
 
13
    $response = wp_remote_get(
14
        'https://api.github.com/repos/' . $github_repo . '/releases/latest',
15
        array(
16
            'headers' => array(
17
                'Accept' => 'application/vnd.github.v3+json',
18
                'User-Agent' => 'WordPress/' . get_bloginfo('version'),
19
            ),
20
        )
21
    );
22
 
23
    if (is_wp_error($response) || wp_remote_retrieve_response_code($response) !== 200) {
24
        return $transient;
25
    }
26
 
27
    $release = json_decode(wp_remote_retrieve_body($response));
28
 
29
    if (!isset($release->tag_name)) {
30
        return $transient;
31
    }
32
 
33
    $latest_version = ltrim($release->tag_name, 'v');
34
    $current_version = $transient->checked[$plugin_slug] ?? '0';
35
 
36
    if (version_compare($latest_version, $current_version, '>')) {
37
        $transient->response[$plugin_slug] = (object) array(
38
            'slug'        => dirname($plugin_slug),
39
            'new_version' => $latest_version,
40
            'url'         => 'https://github.com/' . $github_repo,
41
            'package'     => $release->zipball_url,
42
        );
43
    }
44
 
45
    return $transient;
46
}
47
add_filter('pre_set_site_transient_update_plugins', 'myplugin_check_github_update');

The code does exactly three things: queries the GitHub API for the latest release, compares the version from tag_name with the current plugin version, and if GitHub has a newer one, registers the update in the standard WordPress mechanism. The plugin version is taken from the standard Version: X.Y.Z header in the main file.

Note: for public repositories, no token is needed, but the GitHub API without a token limits request frequency to 60 per hour per IP. For a production plugin with many users, add result caching via set_transient() for 6-12 hours. This way you won't hit the limit every time someone visits the plugins page.

Comparison of approaches

Conclusion: if you're installing someone else's GitHub plugin on a site, use Git Updater. If you're a plugin author distributing it through GitHub, embed auto-updates in the code so users don't have to install an additional plugin.

Setting up the repository for auto-updates

Whichever method you choose, the GitHub repository must be properly prepared. Three mandatory points:

• Plugin header. In the main PHP file, include the standard WordPress header: Plugin Name, Version, Author, and Plugin URI with a link to the repository. Git Updater reads Plugin URI and GitHub Plugin URI; specify at least one.

• Version tags. Accompany each release with a tag: git tag 1.3.0 && git push origin 1.3.0. Without tags, neither Git Updater nor the API request will see the new version.

• Readme file. Add a README.md with a description, changelog, and installation link. Git Updater displays the readme content on the plugin information screen, saving time for users who don't need to visit GitHub for instructions.

With GitHub Actions, you can go further: on tag push, automatically build the ZIP, generate a changelog from commits, and create a GitHub Release with the attached archive. A ready workflow is available in the official GitHub documentation; adapt it for WordPress by replacing the build step with plugin packaging.

The video shows the complete process from installing Git Updater to the first automatic plugin update. We recommend watching before setup: 12 minutes of screen recording will save an hour of experimentation.

⁉️🤔 Frequently asked questions

Does Git Updater work with plugins from the official WordPress.org directory?

Yes, but there's no point. Plugins from WordPress.org already receive updates through the standard mechanism. Git Updater is specifically for plugins and themes that aren't in the directory: custom developments, forks, plugins under review.

Can Git Updater be used on a production site?

Yes, the project is stable and has been maintained since 2015. Before installing, make a full backup (as with any new plugin). On a test site, check the update of at least one plugin, make sure tags in the repository are set correctly and the update applies without errors.

What if the GitHub API hits the request limit?

For public repositories, the limit is 60 requests per hour from one IP. Git Updater caches responses for 12 hours, so the problem rarely occurs. If it does, create a free Personal Access Token (without additional permissions) and add it in Settings → Git Updater: the limit immediately rises to 5000 requests per hour.

What to do if the plugin on GitHub uses Composer dependencies?

Git Updater doesn't run composer install during updates. If your plugin depends on Composer packages, embed autoloading via a bundle (pack vendor/ in the release ZIP) or add a post-update script that checks for dependencies and warns the administrator if they're missing.

Can plugins be updated from a private repository on free GitHub?

Yes. Free GitHub accounts include unlimited private repositories. Create a Personal Access Token with repo permission, add it to Git Updater, and the plugin will gain access to your private repositories.

Auto-updates from GitHub: what to use in 2026

For a site owner, the answer is clear: Git Updater. Free, stable, requires no code.

For a plugin developer, the choice depends on the audience. If your product is installed by regular users, embed the auto-update PHP class directly in the plugin code. An extra intermediary plugin in the chain reduces installation conversion. If the product is for a technical audience, Git Updater as a dependency is acceptable; just mention it in the instructions.

Check your GitHub plugins right now: are tags set on the latest releases, is Plugin URI filled in the header, does the user have a clear update path? Fifteen minutes of setup will save you and your users from manual hassle with ZIP archives for years to come.