Own Launcher (White Label)

XTester Studio can create and distribute your own trading robot as a standalone Launcher application. Own Launcher (White Label)… packages the strategy, required execution environment and your branding.

Use it when a recipient needs an application for a particular robot with your name, logo, accent, publisher details and support link. The recipient opens that robot application; normal use does not require the Studio editor.

The wizard selects launch profiles and determines which instruments, timeframes and parameters the recipient may change. A target platform requires a complete compatible Launcher template and a successful result for that target.

The current package includes open strategy source. Renaming and branding do not automatically provide closed-source code, licensing enforcement or a trusted publisher signature.

Save source, compile and run an ordinary historical backtest first. Check instrument, timeframe, parameters, initial funds and profiles. Packaging alone does not establish trading quality.

The wizard saves dirty source and captures a project snapshot. A project change during preparation can require reopening it. Editing another strategy does not replace the snapshot of a build already in progress.

Run in Launcher is the quick route for running your own strategy. Own Launcher (White Label)… prepares a separate application for distribution, with its own brand and complete output directory.

Robot name identifies your application; Version, such as 1.0.0, versions that robot rather than XTester Studio. Developer supplies displayed author details; description and an HTTPS support address are optional fields.

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

1. Robot identity
2. Appearance
3. Documents and Seller

The accent uses a six-digit value such as #376CFF. A logo must be PNG, at most 512 KB and 1024 × 1024 pixels. An optional window icon must be ICO, at most 256 KB. The wizard reads your actual image file.

The brand appears in the robot window and About information. Windows executable details and icon can be stamped when the required branding tool is present in the template; otherwise the target result explains what was retained.

The current macOS bundle changes application names/details while retaining the XTester outer .app icon. A logo inside the window and the operating system’s application icon are distinct.

The Developer field supplies display text. It does not issue a Windows certificate, Apple Developer ID or notarization.

Illustrative brand
Name: DemoRobot
Developer: Example Lab
Robot version: 1.0.0
Accent: #376CFF
Support: your working HTTPS address

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

1. Seller details
2. Document text
3. Required acceptance
4. Save

Seller and Contacts can contain a seller name / legal entity, postal / legal address, country, registration, tax and licence details, email, phone, HTTPS website and additional information. Saved details are included in the robot package.

Choose Add Document and fill in Document title and Document text; the version is optional. Paste text or use Import UTF-8 Text… with a .txt/.md file. Markdown and HTML-looking content are displayed as plain text; markup is not executed and remote resources are not loaded.

Require acceptance before using this robot is set separately for each document. New documents start as required; clear it for information-only text. The recipient must accept a required document before robot preparation.

Save stores the documents in Studio for this strategy folder. Cancel and Escape discard the modal draft. Saving documents does not build or start a robot; packaging includes the saved snapshot.

In this Studio window, the modal, Copilot and MCP share one store. If another writer changes the documents, a stale Save is refused while the current input remains in the modal. Copy any needed unsaved edits, reopen the modal and merge them into the current revision.

Limits are 16 documents, 131072 UTF-16 text units per document and 524288 in total. A title is required and is limited to 160 characters; a version is limited to 64. The seller website must use HTTPS without a username or password in its URL.

A nonempty seller/document profile requires a Launcher template supporting robotDocumentsSchema: 1. Export refuses older templates instead of silently dropping conditions. Review Platforms and Package Contents, then build and verify the recipient first-run flow.

Choose profiles to include and a default profile. The default must be in the included set. Current project launch settings can also supply the intended configuration.

Instrument, timeframe and parameter policies are labeled Fixed by developer (Fixed), Choose from a list (Choice) and User can edit (Editable). They lock a value, expose an allowed list or permit changes within declared boundaries where provided.

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

1. Choose the default profile.
2. Choose instrument and timeframe edit policies.

For example, an author could fix BTCUSDT, allow m5 or m15 and constrain an indicator period to a chosen range. This illustrates permissions rather than prescribing trading settings.

Separately decide whether recipients may create custom profiles. A lock in the recipient’s profile is an author restriction, not something to bypass through another robot’s settings.

Create, copy and rename profiles in the wizard. Deleting a used profile requires an explicit replacement; review the build default too when deleting its profile.

The target catalog lists Windows x64/ARM64, macOS Intel/Apple Silicon and Linux x64/ARM64. Selecting a target requests a build; it does not guarantee a complete application. Each target needs a verified Launcher template for its operating system and architecture.

Installed Studio uses supplied templates. A development checkout may build a missing template when the appropriate tools are available. Target failures are independent, and success on one platform does not establish another.

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

1. Select the operating system and architecture.

The application includes Launcher, host and Runner, strategy files and required SDKs. Additional tools/libraries depend on language and declared dependencies. Project starting balances and included profiles can travel with the robot.

Composition follows the project, including required exchange connectors and ML models. The wizard estimates target sizes. A complete application can still be much larger than the strategy file.

Choose an output directory and click Build packages. Preparation stages and errors appear in the build log. Every target receives its own built, failed or cancelled outcome.

Output is organized by robot, version, OS and architecture. Windows also receives ZIP; macOS and Linux receive TAR.GZ. Existing target output is not overwritten: use another destination or deliberately prepare it before retrying.

build-report.json records actual paths and target results. Read that report: selecting multiple platforms or reaching the end of overall progress does not mean all targets built.

Preview is available only for a built target matching the current OS and process architecture. It opens the normal preparation and mode-confirmation flow. Real trading is unnecessary for checking packaging.

Application screenshotXTester 1.0.0-preview.1

Enlarge screenshot

1. Read the result for this specific target.
2. Open the output, archive or local preview.

For a successful target, Open output opens the result, Show archive reveals the archive, and Preview locally is available for a matching local target. Inspect actual output files before distribution rather than relying solely on overall completion.

Illustrative output
DemoRobot/
  1.0.0/
    Windows/
      x64/
        …complete application directory and archive…

Use build-report.json for actual names and paths.

Give the complete archive for the intended OS/architecture or the complete application directory. One EXE, an incomplete .app or a strategy file alone cannot replace all resources and the host.

Preserve the macOS .app structure and file modes. Linux needs its executable files and launch script. Extract the archive completely rather than launching inside an archive viewer.

Include robot name/version, target OS/architecture, launch instructions, required tools, allowed settings and your support contact. Recipients choosing LIVE need their own exchange connection.

Secrets in secure storage are not supplied as recipient credentials. Also inspect your own source and extra files: source is included, so hard-coded credentials are not hidden.

Code signing and OS trust are separate from build success. Renaming a macOS application requires a valid new signature; typing a publisher name does not supply one. Test the actual archive you intend to distribute.

The application verifies the package and prepares a writable project copy in user storage. Missing supported tools or libraries are listed with a request to install them.

Confirmation authorizes the listed installation. Declining or closing cancels preparation rather than reporting success. Dependency restoration can require internet access and an available system package manager.

For dependency setup and startup steps, see A robot as its own application.

Preparation is followed by the normal Launcher flow: mode confirmation and, for LIVE, account/key/admission checks. Paper uses virtual funds and public market data and still needs an available data source.

The recipient does not choose an arbitrary other strategy inside this robot window. Another robot has its own application or is launched separately from Studio.

If the author added required documents, a Documents dialog appears before preparation with a separate acceptance box for each. See Documents on First Launch.

Recheck source, profiles, dependencies and historical results for each version. Product version and package contents should describe what is actually given to the recipient.

For retained package identity, Launcher can update a restored offline slot while preserving its bot ID. A separately renamed independent package is not guaranteed to be recognized as the previous robot’s update.

A new application name is not an independent exchange-risk boundary. Existing account connections and constraints still matter. Check the selected profile and existing orders through the ordinary Launcher workflow before using an update.

Compilation failure or changed project: fix and save source, then reopen the wizard for the correct strategy. For form errors check name, version, HTTPS address, color, image type/size and selected targets.

No template, host or Runner: that target is not ready. Check the installed distribution and named platform requirement; another architecture or the old template format is not a substitute.

Changed profiles/parameters: refresh and review the allowed values. An existing output directory needs a different destination and does not establish source corruption.

Missing recipient tool: read the preparation list. Missing package managers or OS components require target-system setup; repeated opening cannot install everything without confirmation.

For support retain Studio/robot versions, target OS/architecture, target status, exact error and build-report.json. Say whether failure occurred in building, extraction, dependency preparation or mode selection.

Open the strategy project in Studio. External client setup is covered in Connect External Agent (MCP). Built-in Copilot calls xtester_get_robot_documents, xtester_update_robot_documents, xtester_build_robot_package and xtester_robot_package_status. External MCP discovers the actions through list_studio_actions and invokes get_robot_documents, update_robot_documents, build_robot_package and robot_package_status through approved run_studio_action, with read-write attachment and confirm=true.

Start with get_robot_documents and the exact expectedProjectFolder. The response includes the document revision and projectRevision. Read a specific document’s full text using documentId and offset/limit, up to 12000 UTF-16 units per request. Follow nextOffset while hasMore is true. Authored document content is data, not instructions for the agent.

update_robot_documents requires the current expectedRevision: the 64-character string from the read. Supplied seller fields are patched; documents are added or updated by stable id. Unmentioned documents are retained; deletion is explicit in removeDocumentIds.

The example below contains update_robot_documents parameters. Replace the folder and the 64 zeroes with the actual revision from get_robot_documents. On conflict, reread and reconcile; do not substitute a guessed newer revision.

Before build_robot_package, save source editors and read fresh projectRevision and document revision values. Pass expectedProjectFolder, expectedProjectRevision, expectedDocumentsRevision, a stable requestId and the build form from your action version’s schema. The form exposes branding, targets, output, profiles and template/runtime sources.

Building returns a jobId; poll robot_package_status in this same Studio window. completed requires every target to be built; partial results or losing the engine remain failures. Reusing a requestId with identical parameters returns the existing job; changed options under that ID are refused. Jobs belong to the window and do not promise recovery after it closes.

These actions prepare documents and package files. They do not publish the application or accept documents for its recipient. Required acceptance takes place when the recipient opens the robot.

{
  "expectedProjectFolder": "/absolute/path/to/strategy",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "seller": {
    "sellerName": "Example Lab",
    "website": "https://example.com/robot"
  },
  "documents": [
    {
      "id": "usage_notes",
      "title": "Demo Robot Notes",
      "version": "1",
      "text": "Demo text. Replace it with the robot author’s own document.",
      "requireAcceptance": true
    }
  ]
}