Skip to content

Run code with cloud-init ​

Cloud-init applies cloud-config user data inside a compatible guest. The public server order schema accepts an image and package specs. It does not expose cloud-init user data at purchase time.

Update stored user data ​

We expose stored user data through Update an instance:

PATCH /v1/instances/{iid}
bash
curl -X PATCH "https://api.galaxygate.net/v1/instances/$INSTANCE_ID" \
  -H "Authorization: Bearer $GALAXYGATE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "user_cloudinit": "#cloud-config\npackages:\n  - htop\n",
    "disable_cloudinit": false
  }'

user_cloudinit is a string or null. Send null to clear it. disable_cloudinit is a boolean that disables vendor cloud-init features when true. Both fields are optional. Omitted fields remain unchanged.

We return 200 OK with the updated instance detail. Saving user data does not execute it in the guest. Guest cloud-init behavior determines when it runs. The public order schema provides no way to guarantee custom user data before the first boot.

A cloud-config example ​

yaml
#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /var/www/html/index.html
    content: |
      Hello from cloud-init
runcmd:
  - systemctl enable --now nginx

The document refreshes package indexes, installs nginx, writes a page, and enables the service when the guest applies it. Encode the document as the user_cloudinit JSON string when saving it.

Next step ​

Read Create a server for package provisioning and Recipes for reusable scripts.