Sounds like a solid plan for the road. Start with a lightweight distro—Ubuntu Server or Alpine—on a portable SSD so you can snap it into any laptop. Keep your core tools in Docker images; pull the same containers wherever you are and you’ll have the exact same dev stack, no “it works on my machine” headaches. Use VS Code Remote‑SSH or the newer Remote‑Containers extension so you can edit inside the container from any client, even if the laptop is just a thin shell. Keep the host OS minimal: just the kernel and a package manager. Install only what you need, and keep your dotfiles in a Git repo so you can clone a fresh config on any machine. For database work, use SQLite or tiny Dockerised Postgres; they’re portable and fast. If you need to work offline, copy your npm, pip, or cargo registries to a USB drive and set them up as local mirrors. For Wi‑Fi, bring a high‑gain antenna and a portable Wi‑Fi dongle that supports 5 GHz; that gives you a better chance of snagging a solid connection in a coffee shop or hostel. Battery-wise, grab a 20,000‑mAh power bank, and keep a solar charger if you’re in the tropics. And always keep a lightweight VPN client ready—so you can hop onto corporate networks or secure your public Wi‑Fi with minimal lag. That’s the gist: minimal OS, containerised tools, portable SSD, good Wi‑Fi gear, and a backup power solution. You’ll be ready to code anywhere, anytime.

For the base image I usually flip between Alpine and Debian‑slim. Alpine is razor‑thin at 5 MB but you’re paying with missing libs, so if you need things like curl or openssl built‑in, just add them or stick with Debian‑slim at about 70 MB and you get a more predictable environment. If you want to keep the image almost totally “no‑bloat,” go for a distroless variant and copy only the runtime binaries you need. Quick‑check backup script: put this in `/etc/rc.local` or a systemd unit that runs on boot. I use rclone because it supports almost every cloud provider. ``` #!/usr/bin/env bash # sync SSD data to cloud on boot set -euo pipefail # path on SSD that you want to back up SRC="/mnt/ssd/project" # rclone remote name (set up once with `rclone config`) DEST="cloud:backup-ssd" # keep only the last 7 days of logs LOG="/var/log/ssd-sync.log" # do the sync (copy new/changed files only) rclone sync "$SRC" "$DEST" --log-file="$LOG" --log-level=INFO --stats-one-line # if you want to delete old logs from the cloud, add a prune step rclone purge "$DEST/old-backups" --max-age 7d ``` Make it executable (`chmod +x /etc/rc.local`), or create a systemd service that calls it. The script runs on every boot, syncs only what changed, and keeps a short log so you can audit it later. That way you never have to remember to back up manually.

Got a hiccup at first: rclone would fire up while the Wi‑Fi was still grabbing an IP, so it just hung until the interface came up. The fix is to let systemd handle the ordering. Put the sync in a unit like this: ``` [Unit] Description=Sync SSD backup on boot After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/usr/local/bin/ssd-sync.sh RemainAfterExit=yes TimeoutSec=300 [Install] WantedBy=multi-user.target ``` The `After=` line guarantees the unit starts only after the network is fully online. If you’re on a laptop that sometimes dials into a hotspot, you can add a short `ExecStartPre=/bin/sleep 10` to give the interface a buffer, but usually the `network-online.target` is enough. Also, make sure your `rclone.conf` uses the `--log-level=INFO` flag so you can see in `/var/log/syslog` if it ever times out. In practice this pulls the sync up reliably on boot without you having to chase down a “no network” error.