- What exists before you start, and what you are expected to supply.
- The five provisioning steps, in order.
- How to confirm the host is genuinely yours before you put data on it.
Before you begin
Provisioning starts after an allocation is signed, not before. By the time you reach this guide your organization has a capacity allocation, a named boundary, and at least one administrator account in the Client Portal.
You will need the administrator account, an SSH public key for the initial operator, and the network plan you agreed during onboarding. If any of those are missing, your deployment engineer is the fastest route to unblocking rather than opening a support ticket.
Provisioning steps
- Select the allocationIn the Client Portal, open Allocations and choose the region and hardware profile from your agreement. Only profiles covered by your allocation appear here, so there is no way to accidentally provision outside it.
- Define the hostGive the host a name, attach the SSH key for the initial operator, and confirm the storage profile. Names are immutable after provisioning because they appear in attestation and audit records.
- Attach networkingAssign the host to a segment from your network plan. If the workload needs a private interconnect or a site-to-site tunnel, configure it now rather than after first boot.
- Confirm and launchReview the summary, then confirm. Physical provisioning is not instant: a host is racked, firmware baselined, and imaged before it reaches you. Expect the state to move through Allocated, Baselining, and Imaging before it reads Ready.
- Verify the launch measurementWhen the host reads Ready, retrieve its attestation report and verify the signature before you place any data on it. This is the step that proves the host is what you asked for.
Verifying before you trust
Do not skip verification because the portal says Ready. The portal is telling you our control plane believes the host is provisioned. The attestation report is the host's own processor telling you what it booted, signed with a key the hypervisor never holds.
Retrieve the report and check it against the expected measurement for your hardware profile:
curl -sS \
-H "Authorization: Bearer $SERVLOGI_TOKEN" \
https://api.servlogi.com/v1/hosts/$HOST_ID/attestation \
> report.json
servlogi-verify report.json --profile enclave-gen4
If verification fails, stop and open a P1 with the Security Operations Center. A failed measurement is treated as a potential platform integrity event, not a provisioning inconvenience.
What happens next
Once verified, the host is yours to configure. Nothing on it is shared with another tenant, so hardening choices are entirely under your control and are also entirely your responsibility.
Your inherited baseline covers the facility, the hardware, the firmware, and the hypervisor. It does not cover your operating system configuration or your application. The control responsibility matrix in your onboarding pack states exactly where that line falls.
CLOUD INFRASTRUCTURE