Trading Bot Setup: Where the Infrastructure Breaks
A trading bot on a server is a process with open positions in real time: an unclosed trade lives only until the next network interruption.
A connection loss to the exchange comes at the worst possible moment — during a sharp move, when the order has already been sent but confirmation has not returned, and the bot does not know whether the order exists.
The second failure point is process restart. A planned update, a configuration error, memory exhaustion: if position state exists only in RAM, losing an order during a failure is almost inevitable.
After startup, the bot sees the account balance differently from the exchange and trades for the first few minutes based on an incorrect picture.
The third is request rate limits. As volatility rises, the request flow grows, the exchange responds with rejections, and some orders are declined.
Bot downtime is measured not by the time it is down, but by the time it operates blind, when the bot considers a position open while the stop has already closed it.
The fourth is the absence of a backup node and logging. One server, no trace of failures — and incident analysis turns into guesswork. Trading bot setup starts with closing each of these points before the first launch: let's break down how this is arranged.
Measurable Effect of Setup: Response, Downtime, Recovery
Response time to a market event changes first. On a local machine, a tick was processed with a delay of several seconds: an unstable channel, background processes, and an order queue on a single core got in the way.
In the cloud, in an AWS zone, response fits within fractions of a second — during news impulses, when the price moves 2–3% in seconds, the bot manages to place and cancel an order without slippage.
Trading bot downtime is measured separately. A home provider outage or power failure resulted in 6–8 hours without trading per month — usually on the most volatile days.
Automatic process restart by the rule “no signs of life for N cycles — bring it back up” reduces unplanned downtime to 10–15 minutes per month.
Recovery time is determined not by restart speed, but by state integrity.
Scheduled disk snapshots and an order journal make it possible to rebuild positions and reconcile them with the exchange: 30–40 minutes of manual reconciliation with the risk of duplicating an order turn into 3–5 minutes of an automated run with a discrepancy report.
A class of failures that was previously simply not tracked is also closed: state desynchronization with the exchange after a partial fill, a process hung without restart, a single point in the form of one machine and one channel.
The share of orders lost for technical reasons in observed periods approaches zero — a failure either causes no downtime or is visible in the moment.
Deployment Modes: Server, Container, Cluster
The choice of platform is determined by three things: how many strategies run simultaneously, how critical the delay between signal and order is, and what happens when a node fails.
Therefore, trading bot deployment is not “where it is cheaper,” but what class of failures you are prepared to accept.
| Option | When it fits | Limitations |
|---|---|---|
| Rented server (virtual machine) | One or two strategies, manual control, quick deployment | Automatic restart and backup node are configured manually, downtime during kernel updates |
| Dedicated host | Sensitivity to execution latency, high request rate to the exchange | Slow deployment, excess capacity for a small number of strategies |
| Container platform | Multiple strategies with different dependencies, frequent releases | Memory limits and external storage for state and keys are required |
| Managed cluster | Fault-tolerant cluster, availability policy, multiple nodes | More complex debugging, manifests, policies, and observability are required |
| Local machine | Logic debugging, historical runs, test scenarios | Depends on home channel and power, unsuitable for real orders |
Switching between options does not require rewriting the strategy: signal logic, risk control, and exchange API interaction are moved into a separate layer, and deployment becomes a replaceable parameter.
On a container platform, this enables quick rollback to the previous image; in a cluster, it enables automatic restart of the pod on another node and a backup node without manual intervention.
For renting a server for a bot, we separately specify health-check, automatic process recovery, and moving state to an external disk, so that node failure does not mean losing positions.
Work Sequence: Audit, Design, Deployment, Verification
Trading bot deployment is not copying files to a server, but a sequence of steps with verification at each one: the logic works with real orders, and an error at this level costs more than the time spent preparing. The sequence below is the same for a new bot and for migrating an already running one.
- Bot architecture audit. We examine where market data comes from, how orders are formed and sent, where access keys and position state are stored. The result is a failure point map: exchange connection loss, time desynchronization, order resubmission after restart.
- Deployment plan. We choose a platform for the load and latency requirements, define the process isolation scheme, permission distribution, secrets handling procedure, and state backup.
- Environment setup. We issue access keys with the minimum required permissions and without withdrawal rights, move parameters into environment variables, synchronize time, and set resource limits so the bot does not crowd out neighboring services.
- Test environment. We run the strategy on historical data and on the exchange test environment, then on minimal volumes. We separately test failure scenarios: connection loss, rejected order, partial fill.
- State monitoring and protection. We configure logs and metrics, alerts about position discrepancies with the exchange, and emergency shutdown under specified conditions — it triggers without human involvement.
- Handover to operations. We provide environment documentation, update and restart procedures, access scheme for your team, and rollback procedure to the previous working configuration.
Handover Package: Configurations, Diagrams, Procedures
We assemble the handover package so that your team can deploy and maintain the bot without our involvement. Everything that was part of trading bot setup on cloud platforms goes into a repository and knowledge base, not into chat history and not into one engineer's head. Below is what exactly remains in your hands.
- Configuration files — launch parameters, trading pairs, position and daily turnover limits, exchange API endpoints; versioned, rollback to the previous set takes minutes.
- Infrastructure diagram — involved nodes, connections between them, failure points, metric and log routes, failover procedure to the backup node.
- Key access rights — role matrix, separate read and trading keys, withdrawal rights disabled, rotation procedure, and secret storage location.
- On-call procedure — who responds to alerts and during which hours, maximum response time, emergency bot shutdown procedure.
- Bot documentation — logic, supported modes, pre-start checks, interpretation of common errors based on log entries.
- Launch and recovery instructions — deployment from scratch, recovery after node failure, migration to another cloud platform.
- Acceptance checklist — scenarios by which you verify operability with your own hands.
We consider the package handed over when your engineer deploys the bot from scratch according to the instructions and restores operation after a deliberately shut down node — without contacting us.
Case Study: The Bot Stopped Losing Orders During Failures
What Was the Situation
The bot traded from a single virtual machine and kept the order queue in process memory: a snapshot to disk was taken once every few minutes.
A restart or migration of the machine to another physical host erased everything that had not been saved — over a month, 12–15 failures accumulated, 6–8 of them with lost orders.
Recovery was manual: reconciling positions with the exchange using logs, up to 40 minutes of downtime, and some trades executed at a worse price than planned.
What We Changed in the Architecture
We moved the bot to two Hetzner nodes in different availability zones: queue state is written to the journal synchronously, before confirmation from the exchange, and each order gets a unique key — a retry during a connection loss does not create a duplicate.
Failover to the backup is automatic, based on availability checks, about ten seconds; a hung connection to the exchange is restarted by a watchdog process, and retries are rate-limited so as not to trigger a block due to request limits.
What the Result Was
Lost orders — zero: each one is either confirmed or safely canceled by key.
The number of failures dropped from 12–15 to 1–2 per month, downtime was reduced from 40 minutes to seconds, and position discrepancies with the exchange, which used to be cleaned up manually, no longer occur.
Failures are no longer regular: bot setup now comes down to planned updates, not nighttime incident analysis.
Technical Concerns: Connectivity, Keys, Limits, Reliability
Engineering concerns about the bot come down to four points: where exchange keys are stored, how to avoid hitting request limits, what happens when the communication channel to the exchange breaks, and how to learn about a failure before it becomes a loss. Below are short answers about how this is arranged in our configurations.
How are exchange access keys stored?
The key is created with trading rights and without withdrawal rights — this cuts off the most expensive class of losses.
The key itself is stored in the cloud provider's secret store and injected into the process environment at startup; it is not present in configuration files, images, or the version control system.
Access to the secret is granted to a separate role and logged, with rotation on team changes or any suspicion of leakage.
What happens if the bot hits exchange request limits?
Limits are counted both per IP and per key, so the request budget is planned for the strategy in advance: reference data is cached, balances and positions are requested in batches, and the order flow goes through a rate-limited queue.
When the exchange responds with a limit notice, the bot pauses with increasing intervals instead of repeating the request — otherwise a temporary block turns into a long one.
The channel to the exchange is down — will the bot trade extra?
The quote stream can freeze silently, so we keep a heartbeat and reconnect with subscription restoration, and after reconnection we reconcile local state with the exchange.
Orders are tagged with our own identifiers, so resubmission does not create duplicates, and process restart continues from the last confirmed state.
How are bot monitoring and notifications arranged?
We collect stream latency, failure rate, discrepancy between local and exchange positions, and downtime.
Thresholds are configured for the strategy: an alert goes to a work messenger, and a separate watchdog signal catches the situation where the process is alive but data is not updating.
Then there is a safe mode: stopping the opening of new orders or canceling active ones, at your choice.
Let's Discuss the Task — We'll Come Back with an Estimate and Work Plan
Trading bot setup is work where a configuration error is immediately visible in the trades: an exchange connection loss at night, a lost stop, or a duplicate order costs more than the infrastructure itself.
To come back with a work estimate and implementation plan, rather than generalities, we need to see your architecture as a whole.
Send us for the task:
- Strategy description: entry and exit logic, working intervals, instrument set, position and per-trade risk limits.
- Current launch architecture: where the bot runs now, what scripts and settings files exist, what you do manually during a restart.
- List of platforms and account types: spot, futures, exchange test environments, and how access keys are stored.
- Fault tolerance requirements: acceptable downtime, whether hot node replacement is needed, bot behavior when the connection to the platform breaks.
- On-call mode: who receives notifications and how, whether round-the-clock response is needed or working hours are sufficient.
- Deployment restrictions: jurisdiction requirements, state backup, and access procedure for our engineers.
With this set, we assemble an implementation plan: migrate the bot to a cloud environment, separate secrets and builds by environment, configure monitoring and automatic restart, run it on the test environment, and only then launch the bot into operation. Describe the task — we'll come back with an estimate and work plan.
Bot on a Server or on a Home Machine: What to Choose?
If the bot trades continuously, a bot on a home machine is the weakest element of the architecture. Running the bot locally is convenient while you are debugging logic, but as soon as positions open without your involvement, any pause turns into an unclosed trade.
Therefore, the home machine remains a development tool, while the production environment lives on a server platform.
The risks of home deployment add up from everyday details. A reboot after a system update, sleep mode, power interruptions, a provider channel outage, a dynamic address behind the router — each of these events stops the process.
A disk without backup and state snapshots means that after a failure you manually restore both the bot itself and the order history.
On a dedicated platform, these failure points are closed separately: the process starts automatically after a restart, a snapshot returns configuration and state to the last working point, external monitoring reports a crash, and key-based access limits the circle of people with rights to trading operations.
At the same time, local launch does not become unnecessary. Running the strategy on historical data, testing logic on a test environment, and preparing configuration are faster to do on your own machine, where there is direct access to logs.
A separate case is key storage requirements: if policy prohibits moving them to a third-party platform, part of the environment remains local.
The difference shows not in trade speed, but in predictability: a home machine offers debugging convenience, a server platform offers continuity.
The working scheme is usually hybrid — logic is prepared locally, the trading part runs on the platform, and configuration transfer between them is documented and repeatable.