Robot Check

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

1. Choose the robot file here when working with a file.
2. Preflight runs through its own button.
3. Robot Backtest requires a robot file.

This panel shows Launcher robots on this computer and offers a separate readiness check. You can work with the open project or choose a robot file. Robot Backtest requires a file.

Preflight checks the market, history, connection, account context and limits. It may access the network and read the connected account, but it does not start a robot or place orders.

Creating and branding a robot application is covered by the separate Own Launcher (White Label) guide.

A robot backtest is a headless backtest of the file by the same engine that computes an ordinary backtest. Keys are not touched.

The run report carries structured fields, model fingerprints among them, which show what the numbers were actually produced with.

When the project’s starting balances fund the robot’s market at release, the robot carries them: the robot backtest and Paper mode start from them, and the deposit stays as the fallback for a market the table does not cover. A live launch does not use them: it trades the real account of the exchange. Such a robot is written with bundle schema v8, and an older launcher refuses to open it — update the launcher. A backtest funded by starting balances is not saved to Strategy Laboratory: the Lab compares backtests funded by one deposit.

Studio shows the checks only. The cockpit, the choice of execution mode, the admission gates and the terminal live in the launcher application itself, not in the editor.

«Run in Launcher» in the Launcher section (and on the Strategies title bar) compiles the robot and hands it to the launcher, which starts it at once. Running it again replaces the version of the stopped robot; a running robot has to be stopped first. «Own Launcher (White Label)…» beside it builds an app of the robot with your name, logo and color.

The app carries only what the robot needs: its exchanges' connectors (all of them when a launch profile may choose any instrument) and the ML runtime only when the strategy has models; the wizard shows the expected size for each platform before the build.

The panel relies only on the calls the engine already answers and does not depict a state it does not have.

A LIVE robot keeps a journal of its own orders on disk. Every order is written before it goes to the exchange; if it cannot be written, the order is not sent. The journal and the order history live in XTester's data folder (Launcher/Orders), the history in monthly files.

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

When the robot crashed, was restarted or updated, its next start compares the exchange with its journal: it takes its resting orders and position back, and explains the orders that filled or were cancelled meanwhile by the exchange's fills. A clean market is not required then.

A crash, a lost connection to XTester, a restart or stop of the service and a server reboot are not a stop: the robot only switches trading off, cancels no orders, keeps the position, and the strategy's OnFinish is not called. It takes all of that over at its next start. The Stop button does what its dialog chose: cancel the orders, close the position, both or neither.

What to do when the exchange differs from the journal (a foreign order, a manual trade, a position that does not add up) is set in the launch profile, section «LIVE Restart»: «Warn and Continue» (the default) — the robot continues and writes the differences to its journal; «Do Not Trade» — it does not enable trading and touches nothing on the exchange; «Ignore» — it continues, the differences stay in the history only. The robot never takes foreign orders as its own.

When the outcome of a request is unknown (it left, no answer came) or the robot was closing its position when it stopped, it does not continue by itself, whatever the setting: a person decides.

The same section sets how many months of order history are kept besides the current one (1 by default, 0 keeps all); older files are removed when the robot starts.

A futures robot's launch profile sets Margin Mode at Start (Cross or Isolated) and Leverage at Start (a whole number, 1–125): in Studio next to Order Poll Interval, in the launcher in the robot profile next to the risk limits. Left empty (0), the robot keeps what the exchange account has. The strategy can still change both from code with SetMarginMode and SetLeverage, through the same calls.

Before a LIVE robot trades, its start sets the account up: first the one-way position mode (the engine trades one-way only), then the margin mode, then the leverage. The start switches a mode only while the market has no position and no open orders; otherwise it is refused and says why. A margin mode is never changed under a position or open orders, nor the leverage raised under them. A backtest and the robot backtest start with the same values.

Binance, Bybit, OKX, Bitget, MEXC, BingX, Gate.io, HTX, BloFin and Kucoin have a one-way mode, which the start switches on when the market is flat. XT, DeepCoin, Weex and CoinW keep long and short apart: the robot keeps one side open, an order against the held side reduces it, and an order that would close the position and open the other side at once is refused — close the position first. Coinbase and Crypto.com have one position per symbol.

The margin mode is set by the exchange's own call on Binance, Bitget, Kucoin, BingX, XT and Weex; with the leverage on MEXC, DeepCoin and BloFin; with each order on OKX; HTX works in the start value's mode for the whole session. On Bybit, Gate.io, CoinW, Coinbase and Crypto.com a different margin mode is set on the exchange: a start value it cannot set refuses the start. HTX and CoinW take the leverage with each order and have no call to read it: without a start value or an open position, set Leverage at Start.

Servers are added on the launcher's Robots tab: address, port, login, and a password or an SSH key file. The password and the key are stored encrypted on this computer only. On the first connection XTester shows the server's key fingerprint: compare it with the one your hosting shows. Later, a server answering with another key is refused.

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

«Set Up Server…» in the server row's menu installs the XTester agent on the server. First comes a check that changes nothing. The server needs Ubuntu 22.04 or later on an x86_64 processor, systemd, at least 2 GB free, and a root login (or a user allowed sudo without a password). Then XTester shows what will be created and what stays untouched, and changes nothing until you press «Set Up».

The setup uploads this Studio's server build and checks its SHA-256 on the server. It then creates the user xtester without a password, the folder /opt/xtester, and the services xtester-agent and xtester-robot@, and gives XTester its own key to sign in as xtester. At the end XTester asks the agent through the SSH connection: no port is opened. The firewall, sshd, Docker/Amnezia, the web server and the root password are not touched.

The setup log goes line by line to the Output panel («XTester: server <name>»). A copy is kept in XTester's data (logs/servers/<name>/) and on the server in /opt/xtester/logs. Passwords and keys never reach the log. Setting up again brings the server to this Studio's version; running robots keep running.

«Reconfigure Server…» takes everything XTester installed off the server and sets it up again. That covers the robots and their data, the exchange keys on the server, the services, /opt/xtester, the users xtester and xtester-logs, and XTester's key (a new one is made). First XTester lists the robots. For a robot trading on an exchange it asks how to stop it: keep the orders and the position, cancel the orders, or cancel the orders and close the position. Nothing is chosen by default. What is not XTester's stays on the server.

If Ubuntu was reinstalled in the hosting panel, the server answers with another key, and its row offers «Accept New Server Key…». XTester shows the old and the new fingerprints. Without a reinstall a changed key means someone may be in between: do not accept it. Once accepted, you can enter the new root password from the hosting panel and set the server up from scratch. A disk cannot be formatted over SSH; that is done in the hosting panel.