Hi Chris,
We checked your server — good news: there is no filesystem corruption and your data is intact. No rescue mode needed.
What actually happened: the OS was hung from memory exhaustion (the kernel logged a burst of OOM kills on the previous boot). Your reboot and the dashboard reboot were both accepted but the shutdown itself hung — the machine only finished powering off at 09:45 UTC and came back up at 09:46 UTC, right after you posted. Since then SSH has been reachable, and we can see an active session from your own network starting 09:47 UTC, so you should already have access — please push your work in those 9 project folders now while everything is up. The disk is healthy (26G of 150G used, root filesystem mounted normally, no errors). The "Transport endpoint is not connected" message does not appear anywhere in the previous boot's system journal, so it most likely came from a FUSE mount in one of your own tools rather than disk corruption.
Two things on the server are still breaking the Zeabur dashboard and need a change on your side:
- Firewall blocks the Kubernetes API. ufw is enabled with default-deny incoming, and port 6443 is not in the allow list. Zeabur's control plane needs that port to read the server status and list your projects — that is why the Status tab is disabled even though the VM shows as running. Fix:
sudo ufw allow 6443/tcp
- nginx occupies ports 80/443. As you mentioned, your host nginx holds those ports, so Zeabur's ingress controller has been crash-looping for weeks. Any domain bound through Zeabur will not route until 80/443 are freed up.
If the server hangs like this again, memory is the first thing to check — the machine has 8GB and no swap, so one heavy host process can lock up the whole box. Adding swap or capping heavy processes would prevent a repeat.
