HHostSSH

Provisioning

Queue and observe evidence-backed VPS provisioning from the operator dashboard.

Provisioning

The Provisioning page is the operator surface for paid provider capacity. Hostinger, Hetzner, DigitalOcean, and Vultr use the same executable, evidence-backed worker contract. Other provider cards remain catalog-only and cannot queue a paid request.

You need the provisioning.manage privilege. Creating a provider Connection also needs connections.manage.

Before a provider can be live

Add the provider through Connections → Add connection → Cloud compute. HostSSH performs a read-only credential check, then encrypts the token in Postgres. It refuses memory-only provider custody. The operator must also configure catalog-to-provider plan and region mappings, the provider image/template/OS, signed enrollment, a dedicated worker secret, the explicit live flag, and a positive monthly spend ceiling. A browser-submitted label, price, or region is never trusted for a paid request. Provider-managed backups are off by default because they may add charges; enable them explicitly in the Connection wizard after checking the provider's current price.

Plan cards show capacity cost hints derived from the approved monthly catalog amount: a 730-hour equivalent, annual run rate, cost per vCPU-month, and cost per RAM GB-month. These are comparison estimates, not live provider quotes or billing rates. They exclude taxes, backups, egress, and usage charges; the provider invoice controls. HostSSH does not assign a subjective “best value” rank.

If any guard is absent, the provider is shown as unavailable and no request can be queued. Provider token environment variables remain labelled legacy fallbacks; encrypted Connections are authoritative.

What happens after Provision new

The request is written to a durable queue. It is not a success toast pretending that a server exists. The worker advances one evidence-backed step at a time:

requested → authorized → provider creating → provider created → booting
          → waiting for agent → agent registered → protection pending
          → protection verified → ready

The row retains its request key, approved server-side plan and price, provider resource ID and IP, attempt count, evidence timestamps, and the latest bounded error. Every state change also has an event-ledger entry.

ready requires all of these facts:

  1. The selected provider returned a durable VPS identity.
  2. The provider reported a running machine with an IP.
  3. A matching HostSSH agent produced a fresh heartbeat and fingerprint.
  4. A successful backup and restore drill were reported after the VPS was created.

A provider accepting a purchase is therefore provider created, not ready.

Failure and recovery behavior

  • An unclaimed request can be cancelled without contacting the provider.
  • Known validation failures become failed with an actionable error.
  • A network or server failure during purchase has an unknown outcome. HostSSH never sends a second blind purchase; it looks up the deterministic hostname first.
  • If that lookup cannot resolve the outcome within the reconciliation window, the row becomes needs attention. Check provider performs lookup-only reconciliation.
  • A request above the configured monthly ceiling fails before the provider POST.

There is deliberately no automatic “retry purchase” button for an uncertain charge. Verify the provider account before creating a replacement request.

Current release boundary

The durable state machine, encrypted credential path, four provider adapters, signed per-request first-boot enrollment, initial protection scheduling, exact-resource destroy/rollback, concurrency tests, and dashboard evidence states are implemented. A release is not yet certified for unattended production provisioning until each chosen provider passes an owner-approved paid sacrificial-VPS staging proof and recovery drill.

No documentation or dashboard state should be read as proof that those live gates have already occurred.

Bring your own box

Existing VPSes, bare metal, and office hardware do not need a paid driver. Install the agent directly using Install on any VPS. BYO nodes join the same Fleet and use the same deployment and recovery surfaces.