Skip to content
WP Deploy
Join early access
Security status · Early access

Trust built from explicit boundaries and honest status.

wp-deploy separates implemented signing, validation, readiness, public-key management, and theme-allowlisting foundations from deployment, storage, job, and recovery capabilities still planned for the MVP.

Report a security issue See how it works
Foundation liveSigned deployment path
Local CLI→REST API→WordPress
Ed25519 request signingImplemented
Admin keys and allowlistsImplemented
Upload, jobs, health, recoveryPlanned
Control status

Implemented foundation versus planned deployment security.

A status label appears beside every control so design intent is never mistaken for an operational guarantee.

Ed25519 key generation and signing

Private keys are generated locally; canonical request-signing primitives exist in the CLI.

Implemented
Exact request-body hashing

The signature model covers the exact transmitted body bytes with SHA-256.

Implemented
Timestamp and replay protection

Verification boundaries include timestamp tolerance, key state, and one-time nonce persistence.

Implemented
Admin key and theme access control

The WordPress admin control plane supports installed-theme allowlisting plus scoped public-key registration, expiration, fingerprints, and revocation.

Implemented
Signed deployment controller

End-to-end deployment creation, package-upload, start, status, and rollback routes are not yet exposed.

Planned MVP
Private artifact storage and jobs

Private ZIP storage, durable jobs, leases, retries, and recovery coordination remain planned.

Planned MVP
Health checks and automatic rollback

Theme-file and activation-state recovery remains an MVP requirement, not a current capability.

Planned MVP
Key boundary

The private signing key stays on the developer machine.

WordPress stores public keys and maps each one to a WordPress identity, allowed operations, allowed theme slugs, expiration, fingerprint, and revocation state.

Important

Signatures do not replace transport security. HTTPS remains mandatory for remote deployment.

Developer machinePrivate keyNever uploaded to WordPress
signed HTTPS request →
WordPress sitePublic keyScoped, fingerprinted, and revocable
Package integrity

Treat every uploaded package as untrusted.

Implemented foundation

Manifest validation

Validate schema, theme identity, requirements, paths, duplicate entries, unsafe integers, checksums, and semantic consistency.

Planned MVP

Path and archive safety

Manifest path checks exist today. Planned ZIP processing adds streaming extraction limits and rejection of malformed archives, links, devices, and unsafe entries.

Planned MVP

Driver boundaries

Planned drivers receive validated theme identifiers and managed artifact handles—not arbitrary caller-controlled paths.

Recovery boundary

Theme recovery is intentionally narrower than site recovery.

The planned rollback model covers theme files and previous activation state. It does not reverse changes a theme may make to the database or other areas of WordPress.

Planned coverage

  • Theme files
  • Previous activation state
  • Parent/child activation relationship

Not covered

  • Database or options changes
  • Content, uploads, plugins, or core
  • Generated files outside the theme directory
Responsible disclosure

Found a security issue?

Use the private security email route. Do not send private keys, passwords, or production theme packages.

Email security