TINY-CLOUD(8)

🦋 tiny-cloud — the manual, but make it make sense 💅

okay bestie, listen. this is the tiny-cloud(8) page from the System Manager's Manual, and it's lowkey the most important thing your cloud instance will ever read on its very first day alive. no cap. we're gonna get through it together. 🫶

---

✨ NAME ✨

tiny-cloud — does the first-boot initialization thing for cloud instances. it's giving "wake up babe, new instance just dropped" energy ✨

🌸 SYNOPSIS 🌸

tiny-cloud [-h|--help] { boot | early | main | final | autodetect |
-b|--bootstrap { complete | incomplete | status } | -E|--enable |
-D|--disable }

like, pick a mode. that's it. that's the vibe check. 🎀

💖 DESCRIPTION 💖

tiny-cloud runs the initialization steps you need to get a cloud instance prepped during first boot. main character energy from the very first millisecond. 🔥

the command operates in phases (more on those below, we love a structured queen 👑). each phase runs a configured list of init actions from tiny-cloud's provider and user-data libraries.

and here's the key part, so don't scroll past it, ngl: after bootstrap has been marked complete, later phase invocations just exit without doing further work. done. finished. go girl give us nothing. 💀

🧚 OPTIONS 🧚

• -h, --help — shows you a short usage summary and then dips. polite. 🎀
• -b, --bootstrap { complete | incomplete | status } — manages the bootstrap state. it's literally the status-keeping option. here's the tea on the three sub-values:
  • complete — marks bootstrap as complete. ✅
  • incomplete — clears the bootstrap-complete marker. poof, gone. 🙈
  • status — prints complete or incomplete. tell me what you are bestie 💅
• -E, --enable — enables the tiny-cloud-boot, tiny-cloud-early, tiny-cloud-main, and tiny-cloud-final services using the detected init system. all four of them!! slay.
• -D, --disable — disables the tiny-cloud services using the detected init system. it's giving "we're so over". 💀

🦋 PHASES 🦋

• boot — runs the default early boot actions. by default this includes bringing up an ephemeral network when needed, saving instance user data, expanding the root filesystem, writing a default network interface configuration, and enabling sshd. busy girl summer. 🔥
• early — runs configured actions after normal networking is available. by default, this just retries saving instance user data if the boot phase didn't already save it. second chances are iconic. 🫶
• main — runs the main configuration actions. by default this creates the default user, sets the hostname, and installs SSH keys. the glow-up phase, fr fr. ✨
• final — runs finalization actions. by default this marks bootstrap complete after any additional configured final actions have succeeded. and here's the Azure lore 👀: on Azure, tiny-cloud reports the instance's provisioning state as ready immediately before marking bootstrap complete. a failed report is retried, and if all attempts fail it prevents bootstrap from being marked complete. no shortcuts, no vibes-based completion. 😤
• autodetect — runs provider autodetection probes and prints the detected provider name. important detail bestie: this does not use the configured provider, kernel command line hints, or the cached autodetection result. it's raw. it's unfiltered. it's fresh out the box. 🦋

🌈 OPERATION 🌈

okay so when you invoke it with a phase argument, tiny-cloud does a little pre-flight:

first, it checks whether /etc/tiny-cloud.disabled exists. if it does, the command logs that tiny-cloud is disabled and exits successfully. respectfully stepping aside. 🙈

then, if bootstrap has already completed, it logs that the system is already bootstrapped and exits successfully. been there, done that, marked complete. 💅

otherwise? the selected phase action list gets loaded from the tiny-cloud init library. each action runs in order. if an action fails, tiny-cloud normally exits with a non-zero status.

but wait — the plot twist 🎀: actions listed in NONFATAL_INIT_ACTIONS are logged as failed but do not stop the phase. by default, this applies to set_ephemeral_network and save_userdata. they get to fail loudly and still keep the party going. iconic behavior honestly.

🔥 BOOTSTRAP NETWORKING 🔥

during the boot phase, tiny-cloud checks whether a network-backed metadata service or remote NoCloud seed already has a route. if not, it picks a connected ethernet interface and does a bounded, single-interface network bootstrap. no sprawling network shenanigans. we stay focused. 💅

when dhcpcd is installed, it's preferred for DHCPv4 and IPv6 RA/SLAAC/DHCPv6. BusyBox udhcpc is the IPv4-only fallback. so:

• IPv4 and IPv6 literal targets request only their respective address families.
• a hostname requests both families concurrently when dhcpcd is available.
• local and file-backed metadata sources do not trigger network bootstrap at all. they don't need it. they're fine. 😌

failure to establish bootstrap connectivity is logged but does not stop later boot actions. and good news: metadata consumers in the main phase get another opportunity to reach IMDS after normal networking is available. retry era. ✨

one more thing — bootstrap-acquired addresses and routes are left in place so later metadata requests stay reachable. the normal networking service may adopt or replace that state after tiny-cloud writes the permanent network configuration. and tiny-cloud does not send a DHCP release during this handoff. no dramatic goodbyes. 🫶

🍓 USER DATA 🍓

the boot phase tries to retrieve and save instance user data before expanding the root filesystem. retrieval and decompression use temporary files, and the saved file is replaced only after the complete operation succeeds. atomic queen. 👑

if no saved user-data file exists, the early phase retries once after normal networking is available. an existing file — including a successfully retrieved empty file — suppresses both attempts. yes, even the empty one counts. ✨

retrieval or save failures are logged but do not stop either phase. user data is attempted at most once in each phase and is not fetched again during main. boundaries. we love them. 💅

🧚 NOCLOUD NETWORKING 🧚

for the nocloud provider, tiny-cloud supports the legacy meta-data network-interfaces and a subset of NoCloud network-config versions 1 and 2.

an existing /etc/network/interfaces is preserved. bestie, do not touch. preserving it. 🙈

unsupported or malformed network-config, and input with no usable physical or ethernet entries, is ignored with a warning; normal network fallback behavior applies when no existing configuration is present. and if you want the full tea on the complete supported format, optional dependencies, and fallback behavior — see network-config(5). it's all there. 🦋

🎀 FILES 🎀

• /etc/tiny-cloud.conf — the main tiny-cloud configuration file. the blueprint. 💖
• /etc/tiny-cloud.disabled — when present, suppresses phase execution. the off switch. 💀
• /etc/network/interfaces — generated network interface configuration. 🧚
• /var/lib/cloud/.bootstrap-complete — the bootstrap completion marker. the little trophy. 🏆
• /usr/lib/tiny-cloud/init — the init library defining the default phase actions. the source of truth. ✨

⭐ EXIT STATUS ⭐

• 0 — success! we ate. 🔥
• 1 — usage error or action failure. it happens to the best of us. 😭

💜 EXAMPLES 💜

run the main configuration phase:

# tiny-cloud main

show bootstrap status:

$ tiny-cloud --bootstrap status

disable tiny-cloud services:

# tiny-cloud --disable

👑 SEE ALSO 👑

imds(1), network-config(5) — go read those too, iykyk. 🫶

---

and that's the whole page, bestie. this one's from the System Manager's Manual, dated 2026-08-24, and it's the TINY-CLOUD(8) entry — so you know exactly where to find it again when your instance wakes up on the wrong side of first boot. 🌸✨ stay bootstrapped, stay iconic. 💅🦋