Setup (broker, margin, products)#
This page is the system’s bill of materials: what you need, why exactly that, and where the breaking points are. I split it into three layers: the account at the broker, the hardware at home, and the software running on top. Fair warning: it’s the page that will age faster than the rest of the site — the models and prices quoted are valid today — but the selection criteria will hold.
The account: broker, margin, products#
The broker of reference for these strategies is Interactive Brokers, for three non-negotiable reasons: it is among the few that grant retail clients portfolio margin and naked index option selling; it has a mature, well-documented API to build on; and it charges some of the most competitive margins and rates in the market. The account should be configured like this: type IBKR Pro (the Lite plan has no API), portfolio margin regime — which requires a minimum equity of $110,000 and an experience questionnaire (Capital efficiency page) — and option trading permissions at the level that allows naked selling, plus futures and futures options if you want ES/MES for hedging (Futures and The DHCS bot pages). Products to enable: US index options (for SPX/SPXW) and CME futures. You then need the real-time market data subscription: the OPRA bundle for options and CME data for futures — a few dollars a month, often waived against commissions generated, and indispensable: a bot deciding on 15-minute delayed data is a bot selling the wrong strikes. Finally, two security precautions: the trusted IP list for API sessions, and above all the twin paper account, which IBKR provides for free and which is the environment where the bot will live out its first months (Execution page).
A note on margin that picks up the Capital efficiency page from the operational side: the API exposes the what-if function, which returns the margin impact of an order before it is sent. The bot uses it as a gate: no order goes out if post-trade margin exceeds the configured threshold (I use a prudent fraction of excess liquidity, because — Capital efficiency page — the requirement doubles on its own on bad days). It is the leverage constraint from the Ergodicity page turned into a line of code that cannot be forgotten.
The hardware: small, dedicated, reachable#
First question: why a computer at home and not a VPS in a datacenter? For low frequency strategies latency is irrelevant (Principle 1: the critical orders rest on the broker’s servers anyway), so the VPS doesn’t buy speed; it buys power and network reliability, and pays for it with a perpetual monthly fee, with account keys and credentials managed on somebody else’s machine, and with an environment you cannot physically touch when something gets truly stuck. My choice is the dedicated home machine — no dual use, no browser, just the bot — with the weaknesses of home (power, internet) mitigated one by one. It is also the cheapest choice: the entire rack I describe costs as much as one year of a decent VPS. I don’t rule out moving to a VPS in the future, but for now I stick to the principle: “if it ain’t broke, don’t fix it”.
The mini PC. The candidate I chose is the GMKtec NucBox G11, around 250 euros: an AMD Ryzen Embedded R2514 processor (four cores, eight threads), an embedded platform designed for continuous industrial use, dual 2.5 Gb Ethernet ports and light-bulb power consumption. As a processor it’s dated stuff — and that’s perfectly fine: IB Gateway plus a Python process that works ten minutes a day occupy a fraction of such a machine, and the real requirement is not power but the ability to stay on 24/7 for years without drama. One caveat: it has a fan, hence a moving part that could die sooner or later — it’s the spare part to keep in the drawer.
The power. A UPS upstream of mini PC and router, connected via USB to the mini PC with the NUT daemon (Network UPS Tools): this way the bot knows it is on battery, can alert me and, if the charge drops below threshold with open positions, run the clean-shutdown procedure after writing its state to the journal. Note the consistency with Principle 2: a blackout with the TRPS in position is not an emergency — the protections, be they daytime stops or the night guard, are already on the broker’s and exchange’s servers, or I enter them myself from mobile — but a bot that dies dirty, halfway through a database write, is the kind of failure that costs a morning of reconciliation.
The network. It is the true single point of failure of the whole contraption, and deserves the largest share of the spend: a primary fiber connection plus an LTE/5G failover (a router with a data SIM that takes over on its own), because the 16:00 window doesn’t wait for the technician. And one non-negotiable security rule: no ports open to the internet on the home router, so as not to expose the machine.
The rack’s bill of materials: dual uplink to the internet, UPS monitored via NUT, the two-way messaging channel to the phone, and no open ports on the router.
The software: few pieces, well watched#
The software layer, from the bottom up: stable Ubuntu Server, headless, automatic security updates and nothing else that updates itself. IB Gateway, the interface-less version of the IBKR platform that exposes the API: it is the most temperamental component of the entire system — expiring sessions, mandatory weekly restarts, authentication windows — and for that reason it must be tamed with IBC, the utility that handles its automatic login and scheduled restarts. The practical rule: the Gateway’s nightly restart is scheduled at a time when by construction nothing happens (for the TRPS, early afternoon New York time, far from both the open and the evening window). On top of the Gateway, the bot proper: Python with the ib_async library (the community evolution of the venerable ib_insync), which wraps the API in a clean event-driven model. State lives in an SQLite database — the journal of Principle 4: every intention written before the order, every outcome after, so that at every restart the bot knows exactly where it left off. The whole thing is orchestrated by systemd: services with automatic restart, explicit dependencies (the bot starts only if the Gateway responds), centralized logs.
Surveillance is layered, from the dumbest to the most paranoid: the systemd watchdog that restarts a dead process; the bot’s internal check that verifies the Gateway connection and data freshness before every action; and the external dead-man switch — a service like healthchecks.io that expects a ping from the bot at every step of the day and sends me a notification if the ping doesn’t arrive. The conceptual point: internal surveillance cannot report the death of its own host; you always need an observer outside the machine.
The piece that ties everything to the phone is the messaging channel, two-way by design. Outbound: every action taken by the trading bots — order sent, fill received, stop triggered, roll completed, MES rebalance, state transition, error — becomes a message on the phone the instant it happens, with the numbers needed to judge it (strike, premium, execution price, remaining margin). Inbound: from the same channel I issue commands — the status command returns positions, live orders and the last heartbeat; the halt command is the kill switch: it stops the state machine, cancels pending non-protective orders and freezes all new activity, leaving the stops on the broker’s servers untouched (shutting down the bot must never mean shutting down the protections — Principle 1 applied to the leash as well); restarting happens only after a clean reconciliation. The implementation is trivial (a messaging service’s API plus a Python library; the messaging process runs separately from the trading bot, so it survives its crashes and can report them), but two security measures are mandatory: the bot answers only my own account — anyone else who writes gets ignored and logged — and the command set respects the asymmetry of the Execution page: from the phone you can stop, you can query, never open positions or raise the size. The phone is a brake, not an accelerator.
One last bit of pedantry worth its weight in gold: the clock. NTP active, and all scheduling expressed in the America/New_York time zone, never in local time — my country doesn’t observe daylight saving, the United States does, and a bot that sells the 1DTEs one hour after the close twice a year is a bot that gets fired.