Cloud-Init User Data

Cloud-init user data profiles let you save reusable #cloud-config YAML and attach them when you launch a VM. Your profile replaces the provider's user-data for that launch. The provider still applies vendor-data and network-data (static IP, DNS, routes): you cannot override those.

Manage profiles at /organization/cloudinit-template under Orchestration → Cloud-Init Templates.

How it works

1. Create a profile: Write #cloud-config YAML and save it in your organisation. You can use placeholders for built-in VM details, environment variables, and secrets.
2. Launch a VM: On create, choose Cloud-init profile and select one profile. Password and SSH key options on the create form are disabled; configure login inside the profile instead.
3. Values are applied at launch: Built-in variables, env vars, and secrets are resolved into your user-data and sent to the VM. The guest runs cloud-init once on first boot.
4. Existing VMs are unchanged: Editing a profile or updating an env var or secret does not re-run cloud-init on VMs that are already running. New values apply only to VMs created after the change.

What you can and cannot change

Built-in placeholders such as {{ vm_network.ipv4_address }} let you read network facts inside your user-data (for config files or scripts). They do not replace the provider's network configuration.

Placeholders in profiles

Profiles support Jinja2 placeholders: expressions in {{ … }} that are replaced with real values when the VM is created.

Basic syntax

Dot notation: {{ vm.name }}, {{ env.APP_ENV }}, {{ secret.API_TOKEN }}

Bracket notation (for keys with special characters): {{ env['MY_KEY'] }}, {{ secret["API_TOKEN"] }}

Filters you should use

Example:

#cloud-config
hostname: {{ vm.hostname | default(vm.name) }}
write_files:
  - path: /etc/myapp/config.env
    content: |
      HOST={{ vm.hostname | tojson }}
      APP_ENV={{ env.APP_ENV | tojson }}
      API_TOKEN={{ secret.API_TOKEN | tojson }}

Built-in variables

These placeholders are filled in from your VM order and assigned networking when the VM is created. Use only the documented names: typos (for example vm.host_name) are flagged when you save the profile.

vm: identity

vm.hashed_passwd and vm.ssh_keys are not available when you use profile auth: set login in the profile itself.

vm_network: networking

Use these in config files or scripts. The provider still configures interfaces via network-data.

Organisation variables (env and secret)

Reference values from your organisation: not the provider's.

Environment variables

Use env.* for non-sensitive configuration: environment names, feature flags, public URLs, and similar.

1. Create a variable (for example key APP_ENV, value staging).
2. Reference it in your profile.
3. When you launch a VM, the current value is written into the final user-data.

#cloud-config
write_files:
  - path: /etc/myapp/env
    owner: root:root
    permissions: "0644"
    content: |
      APP_ENV={{ env.APP_ENV | tojson }}
      LOG_LEVEL={{ env.LOG_LEVEL | tojson }}

See Environment variables for reserved key names.

Secrets

Use secret.* for passwords, API tokens, and other sensitive values. Do not paste secret values into profile YAML: create a secret and reference it by key.

1. Create a secret (for example API_TOKEN). The value is shown once at creation.
2. Reference it in the profile.
3. At VM launch, the value is included in the user-data sent to the guest.

#cloud-config
write_files:
  - path: /root/.config/api_token
    owner: root:root
    permissions: "0600"
    content: {{ secret.API_TOKEN | tojson }}

See Secrets for rotation: running VMs keep the value from create time until you replace them.

Validation warnings

When you save a profile, the UI checks YAML structure and whether each env.* and secret.* reference matches a key in your org. Missing keys show warnings on the profile. You can still save, but fix warnings before production use.

Example profile: login, SSH, and variable dump

This example:

• Sets hostname from the VM order
• Enables SSH password authentication and root login
• Sets a root password in the profile (required because profile auth disables the create-form password field)
• Writes a file listing built-ins, env vars, and secrets for testing

Create matching org entries first: for example env key envtestkey and secret key secrettestkey: or change the references to keys you already use.

#cloud-config
hostname: {{ vm.hostname | default(vm.name) }}

ssh_deletekeys: false
ssh_genkeytypes: [rsa, ecdsa, ed25519]
disable_root: false
ssh_pwauth: true

users:
  - name: root
    lock_passwd: false
    # SHA-512 crypt hash only, e.g. from: mkpasswd -m sha-512
    hashed_passwd: "$6$rounds=656000$exampleSalt$replaceWithYourOwnHash................................"

chpasswd:
  expire: false

runcmd:
  - mkdir -p /etc/ssh/sshd_config.d
  - awk 'BEGIN { print "PermitRootLogin yes"; print "PasswordAuthentication yes" }' > /etc/ssh/sshd_config.d/99-nrings-root-password.conf
  - sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
  - systemctl try-reload-or-restart sshd 2>/dev/null || systemctl try-reload-or-restart ssh 2>/dev/null || true

write_files:
  - path: /etc/nrings-test/all-variables.txt
    owner: root:root
    permissions: "0600"
    content: |
      # Built-ins
      vm.name={{ vm.name | tojson }}
      vm.hostname={{ vm.hostname | tojson }}
      vm_network.mac_address={{ vm_network.mac_address | tojson }}
      vm_network.ipv4_address={{ vm_network.ipv4_address | tojson }}
      vm_network.ipv4_prefix={{ vm_network.ipv4_prefix | tojson }}
      vm_network.ipv4_gateway={{ vm_network.ipv4_gateway | tojson }}
      vm_network.dns_servers={{ vm_network.dns_servers | tojson }}
      # Org variables
      env.envtestkey={{ env.envtestkey | tojson }}
      secret.secrettestkey={{ secret.secrettestkey | tojson }}

Create a profile

Use at VM create

On /platform/virtual-machines/create, choose Cloud-init profile as the authentication method and select a saved profile.

This method is mutually exclusive with password auth and SSH key selection: your profile must configure users, passwords, and/or keys.

Next

• Virtual machines
• Environment variables
• Secrets
• SSH keys