Remote-manage the Raspberry Pi before mounting it

The Pi is going above a drop ceiling, zip-tied to a joist, powered through a barrel connector nobody will see again. Whatever you forgot to configure before that tile went back in, you now configure with a stepladder and a flashlight.

That's the real failure mode with small-board AI: not bad models, bad access. A board that panics on boot, drops off Wi-Fi after an update, or fills its SD card with logs is a five-minute fix at a desk. Above a gate motor or inside a locked cabinet, it's a lost afternoon. These projects rarely die because the model was wrong. They die because nobody could get back in.

Small failures get physically expensive

The constraint is not compute or accuracy. It's distance. A model you can restart from a terminal is a different product than one bolted somewhere you need a ladder to reach. The honest question, before buying the board, is what happens the day it stops responding and you're not standing next to it. If the answer involves a monitor, a keyboard, and a climb, the design isn't done.

Put the control surface on the bench

Key-based SSH with password auth off is the floor. Past that: a watchdog that reboots on a genuine hang instead of a wedged process, time sync so logs and certificates don't drift into nonsense, and an update policy chosen on purpose, not whatever the distro shipped. None of this touches the model. All of it decides whether you touch the model again without driving somewhere.

Settle this before anything gets mounted:

• SSH: key-only, tested from a fresh terminal, not the one that set it up
• watchdog: timeout set, verified by hanging the process on purpose
• health check: confirms the function you care about, not that a port answers
• logs: shipped somewhere readable without SSH access, rotated so the card doesn't fill
• reboot and power-cycle path that doesn't require touching the board

Time the recovery before you need it

A health check that proves a process owns a port proves nothing about whether the porch camera still notices anything. Point it at real behavior instead. Build the reimage procedure before day one, not after a corrupted card forces you to invent one on a stepladder: flash the known image, restore config, confirm the service comes up and passes its own check. Time it.

reimage drill
flash image ..... __:__
restore config .. __:__
service up ....... __:__
health check ..... __:__
total ............. __:__

The rule worth keeping: replacement should be cheaper than heroic repair. None of this is free. Every hour on watchdogs and reimage drills is an hour not spent on the model, and a board wired this way boots slower than the script that got the demo working. I'll take that trade on purpose: a slower board I can fix from my desk beats a fast one I have to visit.