Skip to content

Return the rendered NoCloud seed (system meta-data + customer user-data) the next boot will see.

GET
/v1/projects/{projectId}/compute/instances/{instanceId}/cloud-init/preview
Code sample: Shell / cURL
curl --request GET \
--url https://stratum.example.com/v1/projects/example/compute/instances/example/cloud-init/preview \
--header 'Authorization: Bearer <token>'

. Single source of truth for the cidata ISO bytes the next boot will receive AND the IMDS endpoint will serve — assembled from the same cloudinit package code path the boot-time builder uses, so the UI never re-renders client-side and the server-side and IMDS surfaces can’t drift.

The system meta-data is read-only (it’s derived from the instance row + the linked key pair). To change a field, mutate the underlying resource (rename the instance for hostname, attach/detach a FIP for public-ipv4, etc.). The customer user-data half can be modified via the PUT .../instances/{id}/user-data endpoint (MR1).

With Accept: text/plain the response is the concatenated NoCloud seed: <meta-data>\n---\n<user-data>\n — operator- friendly for curl | less inspection.

projectId
required
string
/^p-[a-z0-9-]+$/
instanceId
required
string
/^i-[a-z0-9-]+$/

Rendered NoCloud seed.

The rendered NoCloud seed an instance’s next boot will see. metaData is the system-generated YAML Stratum auto-injects (always non-empty: includes the instance-id at minimum). userData is the customer-supplied bytes (empty when the instance was launched without user-data and no subsequent PUT supplied any). Each blob is offered in both decoded (UTF-8 string) and base64 forms — UI renders the decoded form; tools that need byte-perfect round-trip use the base64 form.

object
metaData
required

Decoded NoCloud meta-data YAML.

string
metaDataBase64
required

Base64 of the same bytes (binary-safe form).

string
userData
required

Decoded user-data bytes (empty when none).

string
userDataBase64
required

Base64 of the user-data bytes (binary-safe).

string

Example generated

{
"metaData": "example",
"metaDataBase64": "example",
"userData": "example",
"userDataBase64": "example"
}

Resource not found.

Media typeapplication/problem+json
object
type
required
string format: uri
title
required
string
status
required
integer
>= 400 <= 599
detail
string
instance
string format: uri-reference
requestId
required
string
code
required
string
issues

The findings of a rejected IAM policy document (custom and resource policies).

Array<object>

One finding of a rejected IAM policy document. A rejection lists every finding, so the author fixes the document in one round trip.

object
code
required

The finding, e.g. INVALID_DOCUMENT, UNKNOWN_ACTION, ACTION_NOT_APPLICABLE.

string
statement
required

Index of the statement at fault; -1 for the document as a whole.

integer
>= -1
detail
required
string
action

The offending action, where one is at fault (ACTION_NOT_APPLICABLE).

string
errors

Field errors, for codes that carry them: each problem at its field (see FieldError). Documented on the responses that set it, e.g. approveNodeJoin’s INVALID_INPUT and JOIN_APPROVAL_REFUSED. Absent otherwise.

Array<object>

One field’s problem, the stage-2 installer API’s shape. field is the field’s path, message what is wrong with it.

object
field
required

The field’s path, e.g. links[0].interface, disks[1].confirm, mgmt.address or role; empty for the whole request.

string
message
required
string
details

Structured facts about the refusal, for codes that carry them. The shape is fixed per code and documented on the response that answers it, e.g. IMAGE_POOL_MISMATCH (see ImagePoolMismatchDetails) and IMAGE_IN_USE. Absent for codes that carry none.

object
key
additional properties
any

Example

{
"issues": [
{
"code": "ACTION_NOT_APPLICABLE",
"action": "compute:CreateVpc"
}
]
}