[OutOfHere]

Over 900 commits from one person is significant effort!

Here is my feedback, more for users:

1. One should never run a crypto trading bot on Hetzner. Hetzner historically hasn't formally allowed anything to do with crypto. If it sees the words bitcoin or crypto anywhere on disk in a filename or in incoming packets, they can terminate your instance and account without warning, perhaps when you're in a middle of a high-priority trade that needs close attention. It happened to me, and is very dangerous with money on the line.

2. A second reason for not using Hetzner is that its datacenter is geographically probably pretty far from your broker, needlessly adding to much avoidable latency.

3. A third reason for not using Hetzner is that they recently raised the prices unpredictably and dramatically relative to other cloud providers. One needs a provider that won't screw oneself over.

4. If daytrading, it is critical to be able to redeploy and restart the trading bot within seconds. Until the bot's code is stabilized, identified bugs and strategy changes need to be addressed immediately when in the middle of trades. There is no time to rebuild and deploy a container. In contrast, it takes just a few seconds to do `git pull` and restart the Python/Go/TS service. As such, I would never use any container tooling for it. If one is making only long-term trades, then this matters less.

[mercutio93]

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.