Why Freqtrade integration hits the infrastructure ceiling
Algorithmic trading does not break on the strategy. The signal is calculated instantly, but confirming that the order has actually entered the order book, surviving a connection loss and not losing the position is already an infrastructure task.
Freqtrade integration begins exactly where backtesting of the strategy ends: at the junction of trading logic and a real account.
The first bottleneck is a connection drop with the exchange. While the channel is alive, the calculated position state and the actual state on the account match.
If the connection disappears for a few seconds, the sent order remains hanging, while the engine believes the order was not sent. On the next iteration, the logic makes a decision based on the wrong balance — and opens a second position where there should be one.
The second — position mismatch after manual trade entries. The trader sees an opportunity and enters manually, while the automation does not know about this trade. Its calculation of risk, stops and average price becomes incorrect, and any automatic closure turns into a lottery.
The third — lack of control over execution. Partial fills, canceled orders, changes in limits on the exchange side shift the actual position relative to the calculated one.
Therefore, connecting a trading system to an exchange is primarily state reconciliation, handling network failures and separating manual and automatic actions, rather than launching a process.
Let us break down how this is covered.
What connected trading provides: effect in measurable values
An integrated loop is when strategy, execution and risk control work as one system, not as a set of manual operations. Below is what exactly changes in measurable values and by which metrics this is accepted.
- Share of automatic decisions. Automation covers the entire path from signal to order and position management; only risk-limit changes and fund withdrawal remain manual.
- Reaction speed to a market event. A signal turns into an order in fractions of a second — where a human reacts in minutes and usually after the price has already moved.
- Recovery time after a failure. The loop comes back up with the state of open positions restored in minutes, not hours of manual reconciliation.
- Eliminated class of failures. A missed signal due to being busy, an error in order size, loss of connection to the exchange without notification — these failures cease to be possible as a class.
- Execution transparency. The trade log and deviation of the actual execution price from the calculated one are visible in one place, rather than being gathered from exports.
To make the effect of trading automation verifiable, at the start we fix target values for each line — otherwise they remain slogans. We assemble the loop on Freqtrade, and write the surrounding tooling and risk rules to your regulations.
Operating modes: exchange directly, intermediate gateway, own server
Connection mode determines not the speed of launch, but the behavior of the system during a connection loss.
Trading logic can live on the same host where the exchange keys are stored, on a dedicated server near the exchange, or behind an intermediate layer that receives signals and passes them for execution.
The difference is visible at the moment of failure: where the position state is stored, whether the order will be repeated after reconnection and who will notice the mismatch first.
Freqtrade integration begins precisely with choosing this scheme — both the strategy structure and monitoring depend on it. Below are the options that are actually chosen when launching algorithmic trading.
| Operating mode | When it fits | Limitations |
|---|---|---|
| Direct connection to the exchange, local strategy launch | One strategy, one market, quick start and test run without real orders | Keys are stored next to the bot; if the host goes down, an open position remains unmanaged; no signal queue or order resend |
| Intermediate signal gateway | Multiple strategies or exchanges, calculation and execution need to be separated | Added latency for signal transmission; queue control and protection against duplicates on restart are needed; rollback affects two services |
| Own execution server near the exchange | Continuous mode, rate limits on requests, requirement to keep positions in the market | Maintenance, updates and on-call duty are needed; state redundancy is done separately; higher requirements for key protection |
All modes share one common limitation: trading state must be restored after a restart without duplicating orders.
Therefore, in the configuration we fix what the actual position is reconciled against, how the request rate to the exchange is limited and what is considered an emergency shutdown — the bot either manages the position to completion according to the rules or closes it and stops.
Stages of Freqtrade integration implementation: from audit to handover
We structure the implementation stages so that each step relies on the result of the previous one: first we fix the state of trading logic and access, then we assemble the connection scheme, and only then consider the strategy ready for real funds.
- Trading logic audit. We analyze entry and exit rules, stop handling and position sizing, behavior during sharp moves. The output is a list of assumptions that cannot be transferred to automatic mode without verification.
- Connection scheme. We fix market data sources, the method of access to the exchange, storage locations for configurations and logs. We issue keys with limited permissions, without the ability to withdraw funds.
- Environment setup. We deploy the bot in an isolated loop: a separate instance, its own data directories, saving trade state between restarts. The test run does not intersect with production.
- Backtesting. We run the strategy over a long period of quotes taking into account commissions and slippage, and review drawdown and trade distribution. Those weak in profit-to-risk are returned for revision.
- Testing on the test loop. We switch to dry-run mode with live quotes: order triggering, exchange limits, behavior during connection loss and recovery after failure.
- Handover to operation. We bring up the production loop, gradually increase position size, set up failure notifications and an emergency stop procedure, and hand over documentation on configuration and recovery.
Each stage is closed with a report: what was checked, what limitations were found, what remains under control. Going back a step is cheaper than analyzing the bot's behavior on live trades.
Configurations, access keys and procedures: what we hand over after completion
Based on the results of Freqtrade integration, we hand over not a “working bot,” but a package with which your team launches, changes and maintains the system without us. Below is what goes into the repository and internal knowledge base on the day of completion.
- Configuration files — separate profiles for test and production loops, keys only through environment variables, a template describing each parameter.
- Access permission separation — roles “observer,” “strategy operator,” “administrator”; the operator does not change risk limits or position size.
- Key rotation — exchange keys without withdrawal rights and with address binding, a scheduled replacement timeline and a revocation scenario in case of a leak.
- Strategy documentation — for each one: entry and exit logic, indicators, over which historical period it was tested, and under what conditions it is disabled.
- Maintenance procedure — daily checks of data freshness and order status, weekly checks of trade history completeness and backups, and the procedure for process shutdown.
- Interaction scheme — components, data flows, failure points and the procedure for manual intervention.
- Change log — what was changed and when, so that during an incident review the entire chain of decisions can be reconstructed.
We finish with the handover of access and a control run on the test loop: you launch the production loop yourselves, and we remain in touch according to the agreed procedure.
Case study: how manual trading was moved to automatic rules
Before the migration, trading was managed by one person: 5–6 instruments, signals calculated by indicators in the terminal, entry and exit — manually.
Over a three-week period, out of 40+ signals, a third remained unprocessed: some occurred at night and on weekends, some were lost while the trader was managing another trade.
The average delay between signal and entry was minutes, and the rule no longer provided the risk-to-profit ratio for which it had been calculated.
The rules were described formally: entry and exit condition, stop, position size, limit on simultaneous trades.
They were transferred into the Freqtrade configuration and run on history — this filtered out rules that “worked” in manual mode but produced drawdown over a long period.
Then the automation was launched in parallel with manual trading in observation mode, and discrepancies were analyzed using the log until the decisions matched.
After the migration, the share of processed signals was 100% instead of 65–70%, entry latency was seconds instead of minutes, and manual actions per day went from 25–30 to 2.
The class of errors also changed: entries outside the rules disappeared because every trade is written to the log together with its reason.
The log produced a side effect: it is visible which rule is dragging the result down, so one condition is disabled rather than the entire strategy.
Metrics were taken before and after on the same period and using the same methodology — number of trades, share of processed signals, entry latency, maximum drawdown for each pair.
What to do if the trading system is already deployed on your own server?
A running system is not only the strategy code but its state: open positions, placed and unexecuted orders, trade history, balance snapshot and risk management parameters.
Therefore, migration begins not with copying files but with taking an agreed snapshot of this state right during trading.
There is no need to stop the bot for this. We capture a snapshot of the state and configuration, deploy Freqtrade alongside on the target server and launch it in a mode without placing real orders: the system reads the same market data and generates signals.
Comparing signals with the current loop over several trading sessions shows whether indicator calculations, timeframes and entry logic match.
If there are no discrepancies, a phased switch begins: new trades are opened by the new system, while positions accumulated on the old one are managed to completion according to the previous rules until closure.
Separation is by trading pairs or by volume; otherwise the same position will be opened twice — this is the main risk of parallel launch.
Access is migrated separately: exchange keys are issued with trading rights but without withdrawal rights, and the previous loop remains in hot standby.
If the first trades show deviation from expected behavior, rollback takes minutes — history, positions and reporting are preserved in both systems.
Technical concerns: load, exchange access, connection drops
Freqtrade itself is one process that manages a dozen trading pairs: on a server this is almost unnoticeable; the bottleneck is not the CPU but exchange API limits.
The number of requests per minute per key constrains earlier than machine resources, so we set the polling frequency for candles and balance separately from the order placement frequency.
We keep access outside the repository: a key only with trading rights, without withdrawal or transfers, bound to the server IP.
State — open positions, stops, trade history — is written to a local database, so after a connection loss or restart the process restores the position from it rather than opening a duplicate.
What happens if the connection to the exchange drops for several minutes?
The trading loop goes into waiting and retries the connection with increasing delay. As soon as the channel returns, the state is reconciled with the exchange: which positions are actually open, which orders were filled.
Protective stops remain on the exchange side during this time, so the position is not left unattended.
How can you make sure the strategy works and is not overfitted to history?
First, a backtest over several market cycles — with sharp declines, periods of low liquidity, commissions and slippage.
Then trading in observation mode without real orders: the discrepancy between calculated and actual signals shows the difference between the model and the live exchange. We enable the real account with the minimum volume per trade and compare actual execution with expected.
Describe the task — we will come back with an estimate and work plan
To discuss the task and come back with a timeline estimate and work plan for Freqtrade integration, a ready-made technical specification is not needed — it is enough to describe the idea and attach what already exists.
The more specific the input data for the estimate, the fewer assumptions we build into the plan, and therefore the more honest the estimate.
- Trading logic: entry and exit rules, indicators or events on which the strategy makes a decision.
- Markets and instruments: exchanges, spot or futures pairs, whether leverage and commissions need to be accounted for.
- Operating mode: backtest only, trading in test mode or moving trades to real funds.
- Access: test exchange keys without withdrawal rights and repository access if existing work is already available.
- Risk management: position size limit, stop-loss, allowable drawdown, behavior during a connection loss with the exchange.
- Infrastructure and notifications: where the bot is launched, whether state monitoring and messenger alerts are needed.
If some data is not yet defined — this is not a blocker: we will record assumptions in the plan and clarify them before the start.
As a result, you receive a breakdown of work by stages, a timeline estimate and a list of checks that will confirm the strategy's operability before moving it to real funds.