Skip to content
WP Deploy
Join early access
Early access

A signed path from your local theme to WordPress.

The foundation now verifies capabilities, keys, signatures, manifests, and allowlisted theme access. The planned workflow will add authenticated upload, background jobs, and recoverable replacement.

Join early access Explore features
Foundation liveSigned deployment path
Local CLI→REST API→WordPress
Ed25519 request signingImplemented
Admin keys and allowlistsImplemented
Upload, jobs, health, recoveryPlanned
The planned release flow

Eight explicit steps. No hidden upload magic.

Status labels show which foundations exist today and which deployment capabilities remain part of the MVP build.

01

Install and inspect

Install the WordPress plugin, open Tools → Theme Deployments, and inspect runtime capability and readiness checks.

Implemented foundation
02

Generate a signing key

Create an Ed25519 key pair locally. The private key remains on the developer machine.

Implemented foundation
03

Register and scope access

Register public keys, associate a WordPress identity, set expiration or revocation state, and allowlist installed theme targets.

Implemented foundation
04

Build the production theme

Run project build steps, apply inclusion rules, and create a complete theme package.

Planned MVP
05

Validate the manifest

Check theme identity, package paths, requirements, files, sizes, and checksum before upload.

Implemented foundation
06

Upload through signed REST

Send signed metadata and raw ZIP bytes over HTTPS with body hashing and replay protection.

Planned MVP
07

Deploy in the background

Persist the operation, select a safe driver, stage the package, replace the theme, and record progress.

Planned MVP
08

Verify or recover

Run health checks and restore theme files and activation state when required.

Planned MVP
Trust boundaries

The website is never part of the deployment path.

The developer machine holds the private signing key. WordPress stores public keys today; the planned deployment worker will validate every package as untrusted input and select a driver from measured hosting capabilities.

  • ✓TLS remains mandatory for remote deployment
  • ✓GitHub is not required in the deployment path
  • ✓SFTP/SSH is a possible later driver, not the primary connection
Developer machineCLI + private key + theme package
↓ signed HTTPS REST
WordPress pluginAuthorize + validate foundations
↓ persistent operation
Planned deployment driverStage + replace + verify + recover
Proposed API sequence

Separate creation, upload, and execution.

These routes are technical design for the planned deployment API. The capabilities endpoint, CLI doctor/readiness flow, and admin key/theme control plane exist today; deployment creation, upload, status, and rollback remain planned.

GET   /wp-json/theme-deploy/v1/capabilitiesPOST  /wp-json/theme-deploy/v1/deploymentsPUT   /wp-json/theme-deploy/v1/deployments/{id}/packagePOST  /wp-json/theme-deploy/v1/deployments/{id}/startGET   /wp-json/theme-deploy/v1/deployments/{id}POST  /wp-json/theme-deploy/v1/deployments/{id}/rollback
Early access

Follow the MVP from foundation to first safe release.

Join early access for implementation updates and launch availability.

Join early access