RU version is available. Content is displayed in original English for accuracy.
I wasn't interested in deploying my code to managed services like MetaTrader, CTrader or QuantConnect etc because I wanted to have full control over my code and the environment it runs in. I also wanted to be able to run my bots in any programming language I wanted, not just Python. Sometimes I wanted to prototype a bot in Python and then rewrite it in C++ or Rust for performance reasons.
Many at this point would have said why not use a framework like Lean or Freqtrade or Hummingbot. However I found that these frameworks were too opinionated and if you decide to use them then your bot is now part and parcel of their framework. I backtested my bots locally in my own specific way, and now with AI my agents can generate code, backtest and analyze the results all locally, no need to run any of it in the execution platform. I wanted bots I could deploy, version, update and monitor like any other software application. I also wanted to explore building something that creates a standardized way of running bots.
This has been a 4 year journey and I made a lot of mistakes along the way. The application has seen 4 rearchitectures, 3 of which were basically complete rewrites. The first version was a python program and the bots were just modules that were loaded dynamically. The second was my serverless phase when I internally just wanted something that was online cron triggered and only works for me. The third was the first time I was dipping into kubernetes; more cloud native and the idiot in me decided to try make it a SaaS. The final form is a fully self-hosted runtime, api, cli and frontend that let you run bots as containers in a fault tolerant way both locally (through docker `the0 local`) and in a cluster (k8s) and monitor them with a minimalistic frontend.
To support multiple languages there's a thin contract that the bots have to implement: a main(bot_id, config) function and a bot-config.yaml file. The runtime (written in Go) takes care of the rest, it supports C++, Rust, Python, JS/TS, C#, Scala and Haskell for those who are brave enough to try it. More on the architecture here: https://docs.the0.app/runtime
If you want to play with the0 you can run it locally, guide here: https://docs.the0.app/deployment/local-getting-started. The0 is open source and licensed under Apache-2.0: https://github.com/alexanderwanyoike/the0
I currently use the0 to run my own personal algorithmic trading bots on a single node k3s cluster on a $10/month Hetzner VPS. I have 18 bots running on 2 brokers (Alpaca, Bybit) and they have been running for months without issues. Some bots trade crypto, others stocks, some do risk analysis and others invest. Coolest bit is the API provides an MCP server so AI agents can query the state of the bots, look at their logs, monitor them and even update them. Slap an OpenClaw agent and you can effectively setup an autonomous AI quantitative trading system (good luck chasing Alpha).
Now I must admit Lean has all the tools and far more quantitative prowess than the0, but I always felt it does too much. Each Lean engine runs one algorithm, and once you have lots of bots, running and managing all of them in production is left to you. That's the part the0 does, and its the only part it tries to do. If you find hiccups or have ideas for features Im all ears. More on the internals in my first comment.
Discussion (3 Comments)Read Original on HackerNews
The toughest part was getting the Go-written runtime to be able to run arbitrary code in multiple languages. The other tough part was getting the logs and state of the bots to be queryable and streamable in real time. One fun feature is that you can create custom dashboards in React for each bot and stream the logs into them, there is a React sdk that helps you do this. It was a challenge getting this to work and involved treating each bot as a two phased bundle deployment and hydrating the frontend with the state of the bot and metrics from logs (I was inspired by the way Datadog does this).
The way bots send information such as logs and state is done through a daemon process that runs alongside the bot in its container (again inspired by Datadog). The daemon handles what I call the dirty work, persistence of logs and state to the Object Store (MinIO), behind the scenes; the bot just sends information via standard logging and persistence calls from the SDK. Its decoupled, the bot can run without the daemon, but then you lose the ability to query the state of the bot and stream logs.
Stack: the runtime is written in Go and uses NATS for messaging, PostgreSQL, MongoDB and MinIO for persistence. The frontend is React and the CLI is Go. It runs locally through docker or in k8s via helm charts. The0 can theoretically be scaled to run thousands of bots on a k8s cluster (this is based on your own code and the resources you have available).
In terms of whats next... honestly most of the major work is done, the0 is stable and I use it to run my own bots. I think most of the work is in extending the MCP server to support more features and making it easier for AI agents to interact with the bots. The next step is to get some honest feedback on what people want to see in the0 and how they would use it.
Why not just supply a Wasm VM? Are there interesting languages that don't compile to Wasm?
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.