Highlights

• · Uninstalling SpawnBox no longer secretly wipes your servers: the uninstaller offered two checkboxes - 'Delete my SpawnBox data (settings, logs, and server history)' and a separate 'Delete all my Minecraft servers and worlds (cannot be undone)'. Ticking only the first one - which the label promised would just clear settings, logs, and history - was actually deleting your servers and worlds anyway. A note on why this only started biting people now: the underlying mistake had been there for a while, but the SpawnBox container used to stay running in the background even when no servers were active, and that running container kept a file-lock on the virtual disk that holds your worlds. The lock was quietly saving everyone. In 0.2.0-beta.0 we shipped the 'system memory comes back when servers are stopped' feature, which lets the container shut down when idle - that's a real win for users running games or other heavy apps, but it also released the lock and exposed this latent uninstaller bug for the first time. The two checkboxes are now properly independent: the settings/logs/history option only ever touches settings, logs, and history; your worlds, mods, plugins, and player data are only ever deleted when you explicitly tick the second box. Auto-updates were never affected by this and aren't now - your servers stay through every update. As a bonus: if a previous uninstall on your machine already left things in a half-removed state (where the system still 'remembers' SpawnBox's container but the underlying disk is gone), SpawnBox now detects that the next time it runs and clears it cleanly, instead of getting stuck looping 'container is not responding' forever.
• · First-run installs are faster and more deterministic: after 0.2.0-beta.0 we used the install-step telemetry (the same opt-in feature beta.0 introduced) to track down specific places first-run setup was getting stuck or running unusually slow. Several were the kind of issue that's painful to find without real-world data: Ubuntu's automatic-upgrade timers were holding the package manager's lock for ~6 minutes during install (now masked inside the SpawnBox container so they never run), the Ubuntu package mirror was sometimes routing to slow nodes (now points at a Microsoft-hosted mirror with a single health-checked endpoint), a cloud-config template was silently undoing the mirror swap on every reboot (now also rewritten so the swap survives), and a Ubuntu Pro hook we don't actually use was adding ~50 seconds to every package operation by phoning home to check entitlements (now neutered). Long package operations also log a heartbeat now so the install no longer appears stuck while it's actually working. We expect a meaningful share of the long-install cases to be gone, but we don't yet have wide enough signal across diverse networks to declare the class fully closed - if your install still hangs or takes more than a few minutes per phase, please file a Diagnostics report from inside the app. That's how we keep finding the next ones.
• · More observability for the next round of install fixes: first-run install is still one of the top two friction points (the other is server creation), and beta.0's telemetry told us when installs were going wrong but not always why. This release adds finer-grained signals across the install path - which probes ran and which succeeded, which install step ran into which class of network or package error (timeout vs DNS vs TLS vs disk vs network vs apt-specific), and when SpawnBox's auto-repair entered each specific recovery branch (so 'no failures reported' can't be confused with 'recovery never ran'). Same opt-in toggle in Settings, same anonymous data, no personal information.