Athenian Managed Hosting — Growth — Annual

Developer starting point

This page documents the Growth Annual managed-hosting service boundary using the local gated smoke-test source. It does not claim that a tenant, VM, DNS record, WordPress install, credential, or Proxmox mutation has been created.

Control-plane mode

Do not point WordPress directly at Proxmox. WordPress should call a small control plane on the private operations network. That broker owns the Proxmox token, VM template, storage, bridge, guest-agent, DNS, and WordPress bootstrap details.

When the broker contract is implemented and verified, configure the site outside the database:

~~~php define( 'ATH_MH_CONTROL_PLANE_URL', 'https://ops.example.internal' ); define( 'ATH_MH_CONTROL_PLANE_SECRET', 'long-random-secret-held-outside-wordpress' ); define( 'ATH_MH_DRY_RUN', false ); ~~~

The current Athenian operations dashboard is a telemetry and audit surface behind Cloudflare Access. It is not assumed to be a provisioning endpoint. Add the provisioning route only after the broker's Proxmox template, network, backup, and rollback contracts are verified.

Control-plane request contract

WordPress sends:

~~~http POST /v1/hosting/environments Content-Type: application/json X-Athenian-Request-Id: <uuid> X-Athenian-Timestamp: <unix-seconds> X-Athenian-Signature: sha256=<HMAC_SHA256(timestamp + "." + raw_body, shared_secret)> ~~~

~~~json { "idempotency_key": "sha256-request-key", "site_slug": "example-studio", "requested_domain": "example.com", "plan": "smoke", "owner_reference": "ath-mh-user-123", "smoke_test": true } ~~~

The broker should return JSON with an idempotent environment identifier:

~~~json { "environment_id": "pve-smoke-123", "status": "provisioning", "wp_url": "", "wp_admin_url": "" } ~~~

The broker must:

• verify the HMAC, timestamp window, request ID, and idempotency key;
• accept only an allowlisted plan and site template;
• allocate a tenant from a prepared WordPress template rather than accepting arbitrary Proxmox node, storage, bridge, or shell parameters;
• keep tenant data and access paths isolated;
• record the Proxmox VM, guest, DNS, backup, and rollback identifiers in its own audit trail;
• return no password or long-lived credential to WordPress;
• expose an explicit status transition and a retry-safe response;
• fail closed if the template, storage, network, backup, or guest-agent prerequisites are missing.

For the known home Proxmox layout, the broker should run on the private operations side and use the existing least-privilege Proxmox/forced-command pattern. Do not place the Proxmox token in WordPress options or request payloads.

Smoke-test acceptance checks

• Logged-out visitor: sees the gated message.
• Non-allowlisted authenticated user: sees the gated message.
• Allowlisted authenticated user: can submit a request.
• Repeating the same site name returns the same tenant record rather than creating a second one.
• User A cannot retrieve User B's environment by changing an ID.
• Administrator can see the request and run a dry-run provision.
• Dry-run status is visibly labeled and has no live link.
• A failed control-plane request is recorded as failed with a safe error message and can be retried by an administrator.
• No Proxmox credentials are stored in WordPress.

Rollback

Deactivate the plugin to remove its runtime routes and shortcodes. The plugin does not delete tenant records on deactivation. Keep the database tables until the smoke-test audit is intentionally retired; remove them only after exporting the request/event ledger and confirming that no control-plane reconciliation depends on it.