Thanks for this, especially the Hetzner ToS warning, thats genuinely useful and im going to review my own setup because of it. On hosting in general the0 doesnt care where it runs, its docker compose on a laptop or helm on any k8s cluster, so where you host is really an operator decision. Mine is a cheap k3s node cause my bots trade on the order of seconds to minutes. If you are latency sensitive you can host closer to your broker but to be honest I wouldnt even use the0 for actual HFT, that world is colocated bare metal in the exchange datacenter with kernel bypass NICs and hand tuned C++, and the fastest shops do order execution in FPGAs with verilog, a different game entirely.

On point 4 a small correction, theres actually no container build at deploy time. The runtime images per language are prebuilt, the CLI builds/vendors your bot locally and ships a versioned bundle, so an update is just bundle upload + container restart from an already cached image. On a warm node thats seconds, much closer to your git pull loop than a docker build cycle. The genuinely slow step is on the CLI side (dependency vendoring and the upload) not the runtime.

I dont know but I usually get most of the bugs ironed out in backtesting and paper trading runs. Hot-patching a bot mid-trade to me is more of a risk problem than a tooling problem. If a bot of mine misbehaves with positions open I stop it, flatten at the broker and fix it properly before the next session. At that cadence deploy speed stops mattering and versioned bundles mean I can roll back to the last known good bot instantly. But for tight iteration during development I fully agree nothing beats an in-place restart. I actually prototyped a the0 dev mode for a faster local loop and shelved the PR cause I wasnt happy with it, might revisit it to be honest.