Run a Strategy in Production

A backtest does not start a strategy. Production execution is a separate, controlled rollout of an exact project build to infrastructure you operate. The same build contains the installed strategy package, its reviewed configuration, and the runtime that will evaluate closed candles.

The one-command create-tradejs setup is intended for local onboarding. It does not provision a production server, TLS, backups, monitoring, or a container registry. Prepare those services before enabling order placement.

1. Declare the Production Setup

basePreset registers the built-in strategy plugins, but registration does not activate them. The runtime.deployments declaration selects which registered strategies are evaluated and where.

Add a named deployment to tradejs.config.ts. It binds a connector, a stored trading account, a symbol selection, and the complete strategy configuration:

import { basePreset } from '@tradejs/base';
import { defineConfig } from '@tradejs/core/config';

export default defineConfig(basePreset, {
  runtime: {
    deployments: {
      production: {
        label: 'Production',
        connectorName: 'bybit',
        accountId: 'bybit-main',
        enabled: true,
        tickers: ['BTCUSDT'],
        strategies: {
          DoubleTap: {
            enabled: true,
            config: {
              INTERVAL: '15',
              UNIVERSE: 'crypto',
              MAX_LOSS_VALUE: 1,
            },
          },
        },
      },
    },
  },
});

Replace the abbreviated DoubleTap settings with the full configuration you validated. The risk value above illustrates the configuration shape; it is not a recommendation.

The key under strategies must exactly match the registered strategy manifest name. Add more entries to that object to run multiple strategies. Deployment tickers are the default symbol selection; a strategy may declare selection: { tickers: [...] } when it needs its own list.

Create bybit-main in the root user's account settings and give its API key only the required trading permissions. The accountId in the file must match the stored account exactly. Credentials stay in the server's secret storage; never put them in tradejs.config.ts or Git. See Local Root User.

tradejs.config.ts is the source of live settings. Do not copy the deployment or strategy config to Redis. Do not add a numeric strategy version field. TradeJS computes two identifiers during validation:

• strategyRevision identifies the installed strategy package, its TradeJS dependencies, the runtime version, and the parsed effective configuration;
• deploymentCompositionId identifies the complete target, including the connector, account, enabled states, strategies, and symbol selections.

These identifiers let an operator prove what is running without maintaining a manual counter.

2. Build One Reproducible Release

Pin the reviewed package versions, commit tradejs.config.ts, package.json, and the lockfile together, then run the complete checks for your project. A production build must generate and verify the runtime package manifest from the installed packages and the exact project commit.

Build one immutable application image or release artifact and deploy that same artifact to the server. Do not reinstall floating package versions or rebuild from a different checkout on the server.

The project generated by create-tradejs does not currently include the production manifest, image-publication, or server-rollout automation. Do not treat npm run dev as a production launch. Use the official repositories below as a reference or implement equivalent release checks in your own infrastructure before running a live daemon.

The official repository split uses TradeJS-Project for the configuration and application image, and TradeJS-Deploy for production Compose, TLS, volumes, server secrets, and process lifecycle. A custom self-hosted setup may use another container platform or process supervisor, but it must preserve the same exact-build boundary.

3. Verify the Deployed Target

Run these commands inside the deployed project environment, against the same Redis, database, and account that the daemon will use:

npx @tradejs/cli doctor

npx @tradejs/cli runtime-control verify \
  --user root \
  --deployment production

verify must return ok: true and show the expected strategy, account, strategyRevision, and deploymentCompositionId. Stop if the account, package version, interval, universe, or control state is unexpected.

4. Replay the Exact Deployment

Replay recent history with the deployed package and configuration:

npx @tradejs/cli replay \
  --user root \
  --deployment production \
  --days 7 \
  --cacheOnly

Review decisions, missing data, execution differences, and open-position handling. A successful replay is necessary, but it is not evidence of future profitability. If --cacheOnly reports missing coverage, prepare that history without order placement and repeat the replay before continuing.

5. Run Without Orders First

Evaluate the current closed candle once:

npx @tradejs/cli signals \
  --user root \
  --deployment production

Then keep the strategy running in signal-only mode for an observation period:

npx @tradejs/cli signals-daemon \
  --user root \
  --deployment production

Without --makeOrders, TradeJS calculates and records decisions but does not place orders. Confirm candle freshness, expected symbols, signal frequency, rejections, memory use, restarts, and monitoring before proceeding.

Run only one daemon for the deployment. Put it under a process supervisor with restart policy, memory limits, logs, and an alert for missed candle cycles.

6. Enable Order Placement Explicitly

After the pre-live checklist is complete, replace the supervised signal-only command with:

npx @tradejs/cli signals-daemon \
  --user root \
  --deployment production \
  --makeOrders

--makeOrders authorizes order placement; it does not bypass account, risk, strategy, AI, or ML checks. Start with a bounded risk allocation and written stop conditions. Confirm that the previous signal-only daemon has stopped before starting this process.

7. Pause and Resume New Entries

Pause new entries without abandoning management of existing positions:

npx @tradejs/cli runtime-control pause \
  --user root \
  --deployment production \
  --strategy DoubleTap

Resume the Git-enabled strategy:

npx @tradejs/cli runtime-control resume \
  --user root \
  --deployment production \
  --strategy DoubleTap

Pause is a temporary operational control. To change parameters, packages, symbols, accounts, or the permanent enabled state, edit the Git-owned project, build a new immutable release, deploy it, and run runtime-control verify again. Never update live strategy configuration directly in Redis.

For monitoring, rollback, and service ownership, continue with the Production Runbook and How Live Signals Work.