Skip to main content
Open Source · Desktop App for Plugin Developers · by Degird

Deploy WordPress Plugins to WordPress.org Without the SVN Ritual

svnPush takes your plugin from a local folder to a published, verified WordPress.org release — with every version bumped, every check passed, and every SVN change previewed before anything is committed.

Shipping a plugin update to WordPress.org still means Subversion: a working copy, a trunk to sync, a tag to cut, a readme whose Stable tag must match three other places, and a package that must never include your .env file. svnPush turns that into a seven-step checklist. AI can draft the version and changelog from what changed; deterministic checks decide whether the release may proceed; and nothing reaches the repository until you click Publish.

Get svnPush on GitHub
See the Workflow

Free & open source · MIT licence · Windows, macOS & Linux · AI optional

Built for WordPress.org Releases

Four Things a Plugin Release Has to Get Right

Most broken WordPress.org releases fail in one of four places: a version that disagrees with itself, a readme the directory rejects, a file that should never have shipped, or a tag that didn't land. svnPush checks all four before it commits.

Versions Kept in Step
readme.txt Validated
No Secrets Released
Tag Verified on Server

Who It's For

Who Uses svnPush?

Anyone who publishes a plugin to the WordPress.org directory and would rather spend release day on the release notes than on Subversion.

Independent Plugin Developers

You maintain one or two plugins on WordPress.org, you use Git every day, and you touch SVN only when you release — which means every release starts with remembering how. svnPush keeps the procedure in the app, so a release is the same seven steps whether it's your first this month or your first this year.

Agencies With a Plugin Portfolio

Several plugins, several people releasing them. Commit a .svnpush.json to each plugin and everyone releases with the same settings.

Teams Handing Off Releases

The person who ships the release doesn't need to be the one who remembers the SVN commands. The checklist and checks carry the knowledge.

Plugins With a Build Step

Set a pre-build command like npm run build and a package root like dist, and the release ships exactly what the build produced.

Monorepos and Git-First Workflows

Keep docs, tests, and tooling in Git. A .distignore decides what reaches WordPress.org, and plugins in a subfolder list their changes correctly.

Anyone Updating Their Plugin Page Assets

New banner, new icon, new screenshots — but no new version. Update assets syncs and commits only the files in your .wordpress-org folder, with the same preview and confirmation as a full release. The Plugin images card checks every file against the names and pixel sizes WordPress.org expects before you upload, so the directory never quietly ignores a banner because it was 772×249.

Core Features

What svnPush Does

A release flow built around one rule: checks decide, AI only suggests, and you approve every change before it reaches WordPress.org.

01 / 08

Seven Steps, One Checklist

Detect, Changes and draft, Write, Verify, Build, Preview SVN, Publish. Each step shows exactly what it did, so a release is something you watch and approve rather than a script you run and hope about. Turn on Dry run and it rehearses everything up to the SVN preview, then restores your files.

Simple Workflow

How svnPush Works

Set up once, then every release is the same short path: rehearse it, read the preview, publish.

01

Get Ready

Help opens a setup checklist on first launch. Install Subversion in one click (winget on Windows, Homebrew on macOS) and add your WordPress.org SVN password to the vault.

02

Add Your Plugin

Choose the plugin folder and enter its SVN URL. svnPush reads the header and readme; project settings cover build steps, extra version locations, and assets.

03

Dry Run

Approve the draft, read the checks, and inspect the SVN preview. Your files are restored afterwards, so a rehearsal costs nothing.

04

Release

Approve the draft, check the preview, and confirm Publish. The tag is verified on the server and your plugin page opens.

Pricing

Free and Open Source.
MIT Licensed.

svnPush is a developer tool published in the open. No account, no paid tier, and no telemetry — the source is on GitHub under the MIT licence.

Open Source

Everything Included
$0

MIT licence

The complete release app — checklist, checks, readme validator, SVN flow, and optional AI — for Windows, macOS, and Linux.

Seven-step release checklist
17 blocking checks and 12 warnings
Built-in readme.txt validator
Build package, dry run, and update assets
Sparse working copy, SVN preview, and tag verification
Cancel with rollback and resume after trunk commit
Optional AI from Revoye, Gemini, Claude, OpenAI, local models and more
SVN password and API keys in the OS keychain
Get svnPush on GitHub

Requires Subversion 1.10 or newer (svnPush can install it for you) and a WordPress.org plugin you can commit to. Git is optional. Installers are distributed through the project's GitHub releases page and are not code-signed yet, so Windows SmartScreen and macOS ask for confirmation the first time.

Full Feature Set

The Details That Save a Release

Each of these exists because it's a place where a WordPress.org release has gone wrong for somebody.

Dry Run

Rehearse everything up to the SVN preview; your files are restored after.

Cancel & Roll Back

Stop at any step before the trunk commit and nothing is left behind.

Resume

Interrupted after the trunk commit? Resume creates only the tag.

Update Assets

Commit banners, icons, and screenshots with no version change.

Plugin Images Check

Names and sizes checked against what WordPress.org expects (W12).

.distignore Proposal

No ignore file yet? svnPush proposes one for you to review and save.

Pre-Build Command

Run npm run build or similar before the package is assembled.

Extra Version Locations

A file plus a regex with one capture group keeps constants in sync.

Git-Aware Drafts

Changes compared with your last Git tag; commit subjects feed the draft.

Post-Publish Options

Create a matching Git tag and open the plugin page when done.

Ten Kinds of AI Provider

Revoye (recommended), Gemini, Claude, OpenAI, OpenRouter, local models, and more.

Keychain Vault

SVN password and API keys live in the OS keychain, never in a file.

AI Data Notice

See exactly what a provider will receive before it gets anything.

Team Settings File

Commit .svnpush.json and everyone releases the same way.

MIT Licensed

Use it, fork it, and adapt it to your own release process.

Documented Protocol

Every step, check, rollback, and resume is written up in the repo.

Safe by Design

Nothing Is Committed Until You Say Publish

A WordPress.org release is public the moment it lands, and it goes out to every site that updates automatically. That makes the order of operations matter. svnPush checks before it writes, previews before it commits, and verifies after it tags — and your credentials never leave the operating system's keychain. The SVN password reaches svn on stdin, never through a file, a log, or the screen.

What svnPush guarantees before it commits:

Every blocking check passed — versions, readme, required paths, forbidden files, SVN state, and credentials
Every file previewed — each add, modify, and delete in trunk and assets listed before you confirm
No secrets sent anywhere — files that look like secrets never reach a package or an AI provider

The only network requests besides SVN and your chosen AI provider: an optional daily lookup of the current WordPress version on api.wordpress.org, which you can turn off.

Why We Built It

Because Release Day Shouldn't
Depend on Remembering SVN

We publish WordPress plugins to the WordPress.org directory ourselves — GuestDock, AuthDock, and SyncDock all live there. And publishing to the directory means the same Subversion ritual every time: check out the SVN repository, copy the build into trunk, remember which files not to copy, bump the version in the header and the readme and the constant, update the Stable tag, commit, copy trunk to a tag, commit again, and then open the plugin page to see whether it worked.

None of those steps is hard. The trouble is that you do them rarely, from memory, at the end of a long piece of work — which is exactly when a Stable tag gets left behind, a readme fails the directory's parser, or a local .env file rides along into a public zip. The directory is unforgiving about all three, and the mistake ships to every site that updates.

svnPush writes the ritual down and enforces it. The steps are always the same, the checks are deterministic, the AI only drafts text you approve, and nothing is committed until you have seen exactly what will change. We made it open source because the WordPress plugin community has the same problem we did — and because a tool you trust with your SVN password should be one you can read.

Same Steps Every Time

A release is a checklist, not a memory test.

Checks Decide

Deterministic rules gate the release; nothing is left to judgement at 2am.

AI Assists

Drafts the words you'd rather not write. Optional, and never in charge.

Preview Everything

Every SVN change visible before anything is committed.

Keychain Only

Passwords and keys never touch a file or a log.

Open Source

MIT-licensed and built in the open.

FAQ

Frequently Asked Questions

Get Started

Make Your Next Plugin Release the Boring Kind

Clone or download svnPush from GitHub, add your plugin, and run a dry run on your next version. If it saves you one broken release, it's done its job — and if you find a check it should have, open an issue or a pull request.

Get svnPush on GitHub
Read the Release Protocol

Free & open source · MIT · Windows, macOS & Linux · Subversion 1.10+