Skip to content

SpawnWP 0.5.29

Choose a tag to compare

@tts-empire tts-empire released this 30 Jul 08:22
· 34 commits to main since this release

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/status reports connection details, server version, defaults, limits and
    active sites.
  • DELETE /api/provision/connection revokes 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 --yes

Human-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.