Skip to main content

Choose the Provisioning Path

Two provisioning paths reach the same running instance. The prebuilt image is faster and carries a known baseline; cloud-init is repeatable and fits an existing automation pipeline. The wrong choice is not slow — it is unowned, producing instances nobody can rebuild identically. Both paths share one rule: no secret goes into instance metadata.

Compare the two paths

Use the prebuilt image only when the image source, release, checksum or publisher identity, and update path are approved.

Provision the instance

The two paths diverge from here — prebuilt image for the fastest known-good baseline, cloud-init for a reproducible, automation-driven build. Follow whichever one the comparison above pointed to.
The prebuilt image is published at:
Import it through the provider’s custom-image path, then launch an instance from the imported image:
The image ships with the account administrator and the password safesquid. Change it with passwd at first login, before the instance is reachable from any client network. A default credential on a reachable proxy is an immediate exposure, not a setup detail.
Record the image ID, region, launch date, SafeSquid version, disk mapping, and initial security group rules.

Verify after first boot

Whichever path was used, confirm before routing clients:
  • Service and listener state — see Service Health.
  • DNS resolution from the instance.
  • Activation endpoint reachability — see Ports and Firewall Rules.
  • Access-log creation under /var/log/safesquid/access/.
  • The default administrator password has been changed.

Capture provisioning evidence

Store these artifacts with the deployment record:
  • Image ID and region, or the cloud-init file and its version.
  • SafeSquid version at first boot.
  • Disk mapping and initial security group rules.
  • Confirmation that the default password was changed, and by whom.
  • cloud-init-output.log completion, where cloud-init was used.

Troubleshoot provisioning

Next steps