SpawnWP 0.5.29
description: SpawnWP 0.5.29 release notes — scoped provisioning API, official client and safer temporary-site lifecycle.
SpawnWP 0.5.29
SpawnWP can now create short-lived WordPress environments for a trusted integration through a
dedicated, authenticated API. This is intentionally not anonymous public provisioning: an
administrator creates a single-use pairing code in the cockpit and explicitly grants one
integration the narrow provision scope.
A complete provisioning workflow
POST /api/provision accepts a blueprint, lifetime, cockpit group, optional project name and
initial WordPress role. It returns the site URL, generated WordPress credentials and, when
available, a two-minute single-use magic-login link. The default role is Administrator because
evaluation environments commonly need access to plugins, themes and settings; callers can choose
Editor, Author, Contributor or Subscriber for narrower workflows.
Provisioning is synchronous and idempotent. A stable Idempotency-Key safely recovers the same
result after a lost response instead of creating a duplicate site. Each connection owns at most
three API sites by default, independently of the optional host-wide ceiling.
Two companion endpoints complete the lifecycle:
GET /api/provision/statusreports connection details, server version, defaults, limits and
active sites.DELETE /api/provision/connectionrevokes the calling key and removes stored credential
responses. Existing temporary sites remain alive until their normal expiry.
Official zero-dependency client
The new spawnwp-api client handles pairing, Ed25519 signatures, nonces and idempotency without
third-party Python packages. Python 3.10+ and OpenSSL are its only requirements.
spawnwp-api pair 'spawnbp1:...' --label 'Demo integration'
spawnwp-api status
spawnwp-api provision --blueprint development --expires 1h
spawnwp-api revoke --yesHuman-readable output is the default; --json makes provisioning and status suitable for CI or
application automation. Local configuration and private keys are stored with restrictive
permissions.
Capacity and cleanup safeguards
Before a site is reserved, SpawnWP checks the connection quota, the optional host-wide site limit
and free space on every relevant filesystem. Less than 3 GiB free rejects creation before a large
image build can exhaust the host.
Create, destroy and expiry operations now share the same host lock. If WordPress user creation or
magic-login setup fails after the project exists, SpawnWP performs compensating cleanup; a rare
cleanup failure is recorded as cleanup_required with the affected project name.
Temporary-site lifetimes now use seconds throughout, and the installed expiry timer runs every
five minutes. Existing hosts receive both the new timer schedule and the dedicated nginx
provisioning route through idempotent release migrations.
Authentication and documentation
Provisioning reuses SpawnWP's Ed25519 machine authentication with strict scope separation:
blueprint-ingest credentials cannot create sites, and provisioning credentials cannot upload
blueprints. Signed requests enforce a five-minute clock window, one-use nonces and exact-body
SHA-256 binding.
The provisioning guide now begins with a copyable client quickstart and includes CI examples,
credential rotation, error recovery, raw signing details and an OpenAPI 3.1 contract.