EIVUS

Bootstrap New Servers Quickly

Cloud-init, scripts, and config management for repeatable server setup.

Back to blog

Use cloud-init or user data to run scripts on first boot. Ansible, Chef, or Puppet keep config consistent across servers. Store secrets in a vault; never hardcode. Document the bootstrap process.

First boot: cloud-init and user data

  • Cloud-init: Standard on many Linux images. You pass user data (YAML or script) when creating the instance; it runs on first boot. Use it to install packages, create users, write config files, and run one-off commands.
  • User data: Provider-specific (e.g. EC2 user data) often follows the same idea: script or cloud-init config executed at launch. Keep it idempotent where possible; avoid secrets in plain text (use a secrets endpoint or env from a secure store).
  • Limits: User data has size limits; for complex setup, call out to a script hosted elsewhere or use config management in a second phase.

Config management (second phase)

  • Ansible / Chef / Puppet: After the server is reachable, run playbooks or manifests to bring it to the desired state. Handles users, packages, services, and app config. Keeps all servers consistent and version-controlled.
  • When: Trigger from CI/CD after instance creation, or run on a schedule (e.g. Ansible pull). Combine with cloud-init so cloud-init installs Ansible and runs a playbook, or just installs the agent for Chef/Puppet.
  • Secrets: Pull from a vault (HashiCorp Vault, cloud secret manager, or encrypted store). Never put passwords or keys in Git or user data in plain text.

Documentation and repeatability

  • Document: Write a short runbook: what cloud-init does, what config management does, and in what order. So anyone (or an automated pipeline) can bootstrap a new server the same way.
  • Test: Periodically build a new server from scratch using the same process to catch drift and broken assumptions.
  • Version: Keep playbooks and scripts in Git; tag or branch per environment if needed.

Summary

Use cloud-init or user data for first-boot setup; use Ansible/Chef/Puppet for ongoing config. Store secrets in a vault; never hardcode. Document and test the bootstrap process so it is repeatable.

Clients who trust us