The problem
Container platforms are easy until storage becomes read-only, containerd fails to write, an architecture tag is wrong or a service is marked healthy but cannot actually be reached.
What I did
I run several Docker hosts managed through Hawser, including HomeLab, TrueNAS-linked services, Docker-VM application hosts and the AshleyMine game-hosting node, plus a separate ARM64 lab inside an Alpine Podroid environment on Android.
- Operate Portainer CE, Hawser, Yacht and Watchtower across multiple hosts
- Run AshleyMine with a Crafty-managed game container, Hawser agent and Portainer
- Investigated containerd write failures using mount options, disk space, inode use and kernel logs
- Deployed Fing Agent in host-network mode without forwarding its management port to the WAN
- Ran Docker 29.5.2 and Portainer CE 2.39.3 on Alpine ARM64
- Built Nextcloud, Redis and database stacks in the mobile lab
Visible evidence
The evidence here is deliberately platform-level. Dockhand and Portainer are management interfaces over Docker, so these captures demonstrate the container estate without pretending that a container name is a screenshot of the application itself.
Implementation notes
Representative commands from the way I diagnose and maintain this project. Public examples use placeholders instead of credentials or sensitive addresses.
# Check whether storage is writable and has capacity
findmnt -T /var/lib/containerd -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT / /var/lib/containerd
df -i / /var/lib/containerd
# Inspect runtime health and recent failures
systemctl status docker containerd --no-pager
journalctl -u containerd -n 150 --no-pager
docker ps -a
docker inspect <container> --format '{{json .State}}'
# Validate a Compose deployment before applying it
docker compose config
docker compose pull
docker compose up -dResult
The result is experience across ordinary x86 hosts and constrained ARM64 environments, including service recovery rather than only first-time deployment.