Confirm the SolusVM image includes a compatible cloud-init version and that you have access to the supported user-data or application-template workflow. Prepare a disposable guest and a console fallback. Keep the cloud-config file in a private, reviewed repository.

1. Write a minimal #cloud-config document for one clear task, such as installing an authorized public key for the intended administrator. Preserve YAML indentation and use module names supported by the image version.
2. Validate the file with the matching cloud-init schema tooling before deployment. A successful YAML parse alone does not prove that every option is supported.
3. Enter the configuration through the SolusVM workflow available to your role. When building a SolusVM Application, distinguish template variables from the final YAML delivered to the guest.
4. Create a disposable server and wait for initialization. Inside the guest, inspect cloud-init status --long and the protected cloud-init logs.
5. Test the resulting account or service, then repeat with a second fresh server. Publish the template only after both runs produce the intended independent configuration.

On a controlled test system with the cloud-init version used by the guest image, save the final rendered configuration in a private file and validate it:

cloud-init schema --config-file ./user-data.yaml

Replace the filename with your reviewed document. Resolve unsupported fields and validation errors before provisioning. A successful schema check does not run the commands or prove that the target packages, network and accounts work; create a disposable guest and verify the intended result afterward. Keep diagnostics private because error output can include configuration values. Do not reset a production instance merely to repeat this test.

Not reliably. First-boot modules are normally tracked per instance. Use a controlled configuration update for existing machines and reserve image/user-data changes for tested new deployments.

Confirm that initialization completed without errors and the authorized key works in a new connection. Check ownership and permissions on generated files. Verify that logs and application output did not expose credentials, and that package installation used trusted repositories.

For failures, identify the first failing module and inspect the rendered user data rather than repeatedly rebooting. Many initialization actions run once per instance. Do not run cloud-init clean on production merely to retry one command; it can replay configuration and identity changes. Repair a live server deliberately or rebuild the disposable test.

• Preparing a reusable operating-system image in SolusVM 2
• Installing and checking guest tools for a SolusVM 2 server
• Choosing routed or bridged networking in SolusVM 2
• Planning a SolusVM 2 server migration between compute resources

• SolusVM: Applications
• cloudinit.readthedocs.io: CLI
• cloudinit.readthedocs.io: User Groups

• cloud-init CLI: schema