WordPress plugin delivery through GitHub releases

Run a cleaner plugin delivery channel from GitHub.

Git Repos Manager lets WordPress admins discover repositories tagged with wp-plugin, install SHA-256 verified release ZIPs through the native upgrader, and track managed plugins per release channel across single-site and multisite networks — with full WP-CLI coverage.

At a glance Git plugin delivery signals
wp-pluginTopic-based discovery
ChannelsStable and pre-release tracks
SHA-256Verified release ZIP installs
MultisiteNetwork-managed admin
WordPress 6.0+ PHP 8.1+ v1.2.0 stable React admin SPA Encrypted PATs (AES-256-GCM) for public and private repos
Release-ready Native updater Private-safe WP-CLI Multisite

Example admin view for Available Plugins.

The interface works better as a standalone product preview than as a cramped hero aside. This gives the repository list, install actions, and source-profile controls enough horizontal room to read cleanly.

Example admin view -> Available Plugins

A WordPress-native admin screen for browsing eligible repositories, resolving release assets, and deciding which plugins should participate in ongoing update checks.

Repository table
enterprise-api-importerStable channel, SHA-256 verified ZIP
stable
Tracked
Install Now
enterprise-cptPre-release channel for QA networks
pre-release
Untracked
Install Now
private-client-pluginAuthenticated download, active on 3 sites
private
Tracked
Update
Source profiles
Public source
target: tporret
pat: optional when repos are public
Private source
target: client-org
pat: used for private release assets
Controls
cache: refresh + force-flush
lockout: 1h on rate limit
encryption: AES-256-GCM
Repository requirements
Tag the repo Add the wp-plugin topic so discovery stays intentional.
Publish a release Create a GitHub release the plugin can resolve during install and update checks.
Attach a ZIP asset Use a real .zip release asset with application/zip content type.
Publish a .sha256 sidecar Managed installs verify the ZIP fingerprint against the matching .sha256 asset before extraction.
Add PATs only where needed Private repositories can be unlocked per source instead of through one global token.

A repo-backed plugin workflow that stays native to WordPress.

This product keeps GitHub as the source of truth without forcing admins into a foreign interface. Discovery, installation, release metadata, authenticated downloads, and update checks all stay inside WordPress conventions.

Discovery by topic

Repositories only appear when they are explicitly tagged with wp-plugin, which keeps the plugin list intentional instead of dumping every repo in an org.

Native install flow

Release ZIP assets are installed through the WordPress upgrader stack, so the experience stays familiar to admins and compatible with core plugin handling.

Tracked repo lifecycle

Admins mark repositories as Tracked to opt them into update checks. Tracking state is shown separately from WordPress activation, so network-active plugins are not confused with tracked repositories.

Private repo support

Per-source PATs unlock private repositories and authenticated downloads. Tokens are encrypted at rest with AES-256-GCM, masked in the UI, and resolved per repository owner. Classic ghp_, fine-grained github_pat_, and newer gh* token prefixes are all accepted.

Cache and lockout controls

Repository and release payloads are cached, a rate-limit lockout prevents thrashing the API, and the settings page exposes a force-check utility when you need fresh data now.

Operational clarity

Auth failures, missing releases, bad ZIP assets, and not-found responses are surfaced with explicit admin-facing error messages instead of silent failure modes.

Release channels

Set a default channel and override per plugin to choose between stable and pre-release tracks. The updater respects the configured channel when resolving the next release.

WP-CLI coverage

Manage sources, channels, cache, and plugin install/update/uninstall from the command line: wp gpw source, wp gpw channel, wp gpw cache flush, wp gpw plugins.

Multisite-native

A dedicated Network Admin screen manages sources, encrypted tokens, tracked repos, cache, and diagnostics at the network level. A Sites column gives super admins lazy-loaded per-subsite activation details.

SHA-256 verified installs

Managed installs and updates download the release ZIP plus its .sha256 sidecar, compute the fingerprint locally, and refuse extraction on mismatch. Verification state is surfaced in the admin UI and CLI output.

Connect sources first. Distribute plugins second.

The setup flow is straightforward, but the product stays opinionated where it matters: source-level credentials, topic filtering, release asset validation, and explicit active-repo selection.

01
Open Git Plugins -> Settings

Add one or more GitHub user or organization targets. Each source can carry its own optional PAT. On multisite, use Network Admin -> Git Plugins.

02
Publish your repository correctly

Use the wp-plugin topic, create a release, attach a real .zip asset, and publish a matching .sha256 sidecar.

03
Review Available Plugins

The plugin builds a clean list of eligible repositories, resolves the latest release on the chosen channel, and exposes install actions and a Tracked toggle.

04
Force fresh checks when needed

Use Refresh or Force Refresh Cache from the settings page to flush cached GitHub data and re-run update checks — or drive the same workflows with wp gpw commands.

Settings page

Repeatable source rows

Each source stores a target name and optional PAT. That makes public orgs, private client repos, and mixed environments manageable without awkward credential reuse.

Repository rules

Release asset discipline

The installer prefers ZIP assets from the latest published release and falls back carefully, which means your release process stays explicit and auditable.

WordPress fit

Admin-native install actions

Install, uninstall, active-state saving, settings notices, and update integration all sit inside WordPress conventions instead of bolted-on custom flows.

Private delivery

Owner-matched token lookup

The plugin resolves a token per repository owner, which is the right mental model when one admin instance needs to talk to multiple GitHub accounts or orgs.

From GitHub release to WordPress update notice.

The product story here is operational confidence: discover repos, install from release assets, keep selected plugins active for checks, and let WordPress core surface version changes in a familiar way.

Release handling
01
Fetch repository list

Query configured users or orgs and filter down to repos that explicitly declare themselves as WordPress plugins.

cached
02
Resolve channel release

Pull the newest release on the configured stable or pre-release channel, fall back to release lists when needed, and reject incomplete release metadata.

release
03
Verify and install ZIP asset

Download the ZIP plus its .sha256 sidecar, verify the fingerprint locally, then hand the archive to the native upgrader with GitHub auth headers scoped to approved hosts.

verified
04
Track repos for updates

Only repositories marked Tracked are included in ongoing update checks. On multisite, tracking is network-wide while activation still follows site-active vs network-active rules.

tracked
Timestamp Event Source
09:12:04 Repository list cached from client-org after topic filter matched 4 plugin repos. api
09:12:06 Latest stable release found for tporret/enterprise-api-importer with ZIP and .sha256 assets. release
09:12:08 SHA-256 fingerprint verified locally, then private download handed off to the WordPress upgrader with owner-matched PAT. install
09:12:10 Update check injected into core plugin updates for repositories currently marked Tracked across the network. update

Built for admins who need predictable behavior, not magic.

The strongest part of the product is restraint. It narrows discovery, validates releases, scopes credentials by source, and handles bad API states explicitly.

Rate limits

One-hour lockout

When GitHub rate limiting is detected, requests pause instead of hammering the API. That protects both reliability and operator sanity.

Token safety

Encrypted, host-scoped PATs

PATs are encrypted at rest with AES-256-GCM, masked in the UI, and only decrypted for outbound calls. Authorization headers are injected exclusively for approved GitHub hosts, and salt-rotation detection prompts re-entry when keys change.

Release integrity

SHA-256 verified extraction

Managed installs require a matching .sha256 sidecar. The plugin computes the ZIP hash locally and aborts before extraction on mismatch, with verification state surfaced in the admin UI and WP-CLI output.

Boundary validation

Capability-checked REST routes

Settings and plugin action endpoints require WordPress capabilities (manage_options, install/delete plugin caps) and validate repository identifiers, plugin files, channel values, and multisite pagination before any action runs.

Errors that explain themselves

Useful admin notices

Missing releases, invalid repo names, auth failures, and transport problems surface as actionable WordPress notices instead of vague silent breakage.

Multisite governance

Network-scoped configuration

On multisite, sources, encrypted tokens, tracked repos, cache, and diagnostics live at the network level — with a Sites column that lazy-loads per-subsite activation details for super admins.

Turn GitHub releases into a real plugin channel.

Git Repos Manager is for teams that want WordPress-native installs and updates without giving up GitHub as the source of truth for plugin distribution.

v1.2.0 WordPress 6.0+ PHP 8.1+ GitHub Releases Release channels SHA-256 verified Multisite ready WP-CLI Encrypted PATs GPLv2 or later