Advanced Post-installation Tasks

This page explains some advanced tasks and configuration options that can be performed after the bot installation and may be useful in some environments.

If you do not know what things mentioned here mean, you probably do not need it.

Running multiple instances of Freqtrade

This section will show you how to run multiple bots at the same time, on the same machine.

Things to consider

• Use different database files.
• Use different Telegram bots (requires multiple different configuration files; applies only when Telegram is enabled).
• Use different ports (applies only when Freqtrade REST API webserver is enabled).

Different database files

In order to keep track of your trades, profits, etc., freqtrade is using a SQLite database where it stores various types of information such as the trades you performed in the past and the current position(s) you are holding at any time. This allows you to keep track of your profits, but most importantly, keep track of ongoing activity if the bot process would be restarted or would be terminated unexpectedly.

Freqtrade will, by default, use separate database files for dry-run and live bots (this assumes no database-url is given in either configuration nor via command line argument).

For live trading mode, the default database will be tradesv3.sqlite and for dry-run it will be tradesv3.dryrun.sqlite.

The optional argument to the trade command used to specify the path of these files is --db-url, which requires a valid SQLAlchemy url.

So when you are starting a bot with only the config and strategy arguments in dry-run mode, the following 2 commands would have the same outcome.

freqtrade trade -c MyConfig.json -s MyStrategy
# is equivalent to
freqtrade trade -c MyConfig.json -s MyStrategy --db-url sqlite:///tradesv3.dryrun.sqlite

It means that if you are running the trade command in two different terminals, for example to test your strategy both for trades in USDT and in another instance for trades in BTC, you will have to run them with different databases.

If you specify the URL of a database which does not exist, freqtrade will create one with the name you specified. So to test your custom strategy with BTC and USDT stake currencies, you could use the following commands (in 2 separate terminals):

# Terminal 1:
freqtrade trade -c MyConfigBTC.json -s MyCustomStrategy --db-url sqlite:///user_data/tradesBTC.dryrun.sqlite

# Terminal 2:
freqtrade trade -c MyConfigUSDT.json -s MyCustomStrategy --db-url sqlite:///user_data/tradesUSDT.dryrun.sqlite

Conversely, if you wish to do the same thing in production mode, you will also have to create at least one new database (in addition to the default one) and specify the path to the "live" databases, for example:

# Terminal 1:
freqtrade trade -c MyConfigBTC.json -s MyCustomStrategy --db-url sqlite:///user_data/tradesBTC.live.sqlite

# Terminal 2:
freqtrade trade -c MyConfigUSDT.json -s MyCustomStrategy --db-url sqlite:///user_data/tradesUSDT.live.sqlite

For more information regarding usage of the sqlite databases, for example to manually enter or remove trades, please refer to the SQL Cheatsheet.

Multiple instances using docker

To run multiple instances of freqtrade using docker you will need to edit the docker-compose.yml file and add all the instances you want as separate services. Remember, you can separate your configuration into multiple files, so it's a good idea to think about making them modular, then if you need to edit something common to all bots, you can do that in a single config file.

---
version: '3'
services:
  freqtrade1:
    image: freqtradeorg/freqtrade:stable
    restart: always
    container_name: freqtrade1
    volumes:
      - "./user_data:/freqtrade/user_data"
    ports:
      - "127.0.0.1:8080:8080"
    command: >
      trade
      --logfile /freqtrade/user_data/logs/freqtrade1.log
      --db-url sqlite:////freqtrade/user_data/tradesv3_freqtrade1.sqlite
      --config /freqtrade/user_data/config.json
      --config /freqtrade/user_data/config.freqtrade1.json
      --strategy SampleStrategy
  
  freqtrade2:
    image: freqtradeorg/freqtrade:stable
    restart: always
    container_name: freqtrade2
    volumes:
      - "./user_data:/freqtrade/user_data"
    ports:
      - "127.0.0.1:8081:8080"
    command: >
      trade
      --logfile /freqtrade/user_data/logs/freqtrade2.log
      --db-url sqlite:////freqtrade/user_data/tradesv3_freqtrade2.sqlite
      --config /freqtrade/user_data/config.json
      --config /freqtrade/user_data/config.freqtrade2.json
      --strategy SampleStrategy

You can use whatever naming convention you want, freqtrade1 and 2 are arbitrary. Note, that you will need to use different database files, port mappings and telegram configurations for each instance, as mentioned above.

Use a different database system

Freqtrade is using SQLAlchemy, which supports multiple different database systems. As such, a multitude of database systems should be supported.

Freqtrade does not depend or install any additional database driver. Please refer to the SQLAlchemy docs on installation instructions for the respective database systems.

The following systems have been tested and are known to work with freqtrade:

• sqlite (default)
• PostgreSQL
• MariaDB

注意

By using one of the below database systems, you acknowledge that you know how to manage such a system. The freqtrade team will not provide any support with setup or maintenance (or backups) of the below database systems.

PostgreSQL

Installation:

pip install psycopg2-binary

Usage:

... --db-url postgresql+psycopg2://<username>:<password>@localhost:5432/<database>

Freqtrade will automatically create the tables necessary upon startup.

If you're running different instances of Freqtrade, you must either setup one database per Instance or use different users / schemas for your connections.

MariaDB / MySQL

Freqtrade supports MariaDB by using SQLAlchemy, which supports multiple different database systems.

Installation:

pip install pymysql

Usage:

... --db-url mysql+pymysql://<username>:<password>@localhost:3306/<database>

Configure the bot running as a systemd service

Copy the freqtrade.service file to your systemd user directory (usually ~/.config/systemd/user) and update WorkingDirectory and ExecStart to match your setup.

备注

Certain systems (like Raspbian) don't load service unit files from the user directory. In this case, copy freqtrade.service into /etc/systemd/user/ (requires superuser permissions).

After that you can start the daemon with:

systemctl --user start freqtrade

For this to be persistent (run when user is logged out) you'll need to enable linger for your freqtrade user.

sudo loginctl enable-linger "$USER"

If you run the bot as a service, you can use systemd service manager as a software watchdog monitoring freqtrade bot state and restarting it in the case of failures. If the internals.sd_notify parameter is set to true in the configuration or the --sd-notify command line option is used, the bot will send keep-alive ping messages to systemd using the sd_notify (systemd notifications) protocol and will also tell systemd its current state (Running, Paused or Stopped) when it changes.

The freqtrade.service.watchdog file contains an example of the service unit configuration file which uses systemd as the watchdog.

备注

The sd_notify communication between the bot and the systemd service manager will not work if the bot runs in a Docker container.

Advanced Logging

Freqtrade uses the default logging module provided by python. Python allows for extensive logging configuration in this regard - way more than what can be covered here.

Default logging format (coloured terminal output) is set up by default if no log_config is provided in your freqtrade configuration. Using --logfile logfile.log will enable the RotatingFileHandler.

If you're not content with the log format, or with the default settings provided for the RotatingFileHandler, you can customize logging to your liking by adding the log_config configuration to your freqtrade configuration file(s).

The default configuration looks roughly like the below, with the file handler being provided but not enabled as the filename is commented out. Uncomment this line and supply a valid path/filename to enable it.

{
  "log_config": {
      "version": 1,
      "formatters": {
          "basic": {
              "format": "%(message)s"
          },
          "standard": {
              "format": "%(asctime)s - %(name)s - %(levelname)s - %(message)s"
          }
      },
      "handlers": {
          "console": {
              "class": "freqtrade.loggers.ft_rich_handler.FtRichHandler",
              "formatter": "basic"
          },
          "file": {
              "class": "logging.handlers.RotatingFileHandler",
              "formatter": "standard",
              // "filename": "someRandomLogFile.log",
              "maxBytes": 10485760,
              "backupCount": 10
          }
      },
      "root": {
          "handlers": [
              "console",
              // "file"
          ],
          "level": "INFO",
      }
  }
}

Explicit log configuration

We recommend to extract the logging configuration from your main freqtrade configuration file, and provide it to your bot via multiple configuration files functionality. This will avoid unnecessary code duplication.

Logging to syslog

To send Freqtrade log messages to a local or remote syslog service use the "log_config" setup option to configure logging.

{
  "log_config": {
    "version": 1,
    "formatters": {
      "syslog_fmt": {
        "format": "%(name)s - %(levelname)s - %(message)s"
      }
    },
    "handlers": {
      "syslog": {
         "class": "logging.handlers.SysLogHandler",
          "formatter": "syslog_fmt",
          "address": "/dev/log"
      }
    },
    "root": {
      "handlers": [
        "syslog"
      ]
    }
  }
}

Syslog addressing

The syslog address can be either a Unix domain socket (socket filename) or a UDP socket specification, consisting of IP address and UDP port, separated by the : character.

So, the following are the examples of possible addresses:

• "address": "/dev/log" -- log to syslog (rsyslog) using the /dev/log socket, suitable for most systems.
• "address": "/var/run/syslog" -- log to syslog (rsyslog) using the /var/run/syslog socket. Use this on MacOS.
• "address": "localhost:514" -- log to local syslog using UDP socket, if it listens on port 514.
• "address": "<ip>:514" -- log to remote syslog at IP address and port 514. This may be used on Windows for remote logging to an external syslog server.

Logging to journald

This needs the cysystemd python package installed as dependency (pip install cysystemd), which is not available on Windows. Hence, the whole journald logging functionality is not available for a bot running on Windows.

To send Freqtrade log messages to journald system service, add the following configuration snippet to your configuration.

{
  "log_config": {
    "version": 1,
    "formatters": {
      "journald_fmt": {
        "format": "%(name)s - %(levelname)s - %(message)s"
      }
    },
    "handlers": {
      "journald": {
         "class": "cysystemd.journal.JournaldLogHandler",
          "formatter": "journald_fmt",
      }
    },
    "root": {
      "handlers": [
        "journald"
      ]
    }
  }
}

Log messages are send to journald with the user facility. So you can see them with the following commands:

• journalctl -f -- shows Freqtrade log messages sent to journald along with other log messages fetched by journald.
• journalctl -f -u freqtrade.service -- this command can be used when the bot is run as a systemd service.

Log format as JSON

You can also configure the default output stream to use JSON format instead. The "fmt_dict" attribute defines the keys for the json output - as well as the python logging LogRecord attributes.

The below configuration will change the default output to JSON. The same formatter could however also be used in combination with the RotatingFileHandler. We recommend to keep one format in human readable form.

{
  "log_config": {
    "version": 1,
    "formatters": {
       "json": {
          "()": "freqtrade.loggers.json_formatter.JsonFormatter",
          "fmt_dict": {
              "timestamp": "asctime",
              "level": "levelname",
              "logger": "name",
              "message": "message"
          }
      }
    },
    "handlers": {
      "jsonStream": {
          "class": "logging.StreamHandler",
          "formatter": "json"
      }
    },
    "root": {
      "handlers": [
        "jsonStream"
      ]
    }
  }
}

Best Practices

Multiple Instance Management

1. Use descriptive names for databases and log files
2. Separate configurations for different strategies or markets
3. Monitor resource usage when running multiple instances
4. Use different ports for API access
5. Implement proper logging to track each instance separately

Database Management

1. Regular backups of your trading databases
2. Monitor database size and implement rotation if needed
3. Use appropriate database systems for your scale
4. Separate databases for different trading environments

Service Management

1. Use systemd for production deployments
2. Implement monitoring and alerting
3. Configure log rotation to prevent disk space issues
4. Set up proper error handling and restart policies

Security Considerations

1. Restrict API access to localhost only
2. Use strong passwords for database connections
3. Implement proper file permissions for configuration files
4. Regular security updates for the system and dependencies