Freqtrade provides a builtin webserver, which can serve [FreqUI](https://github.com/freqtrade/frequi), the freqtrade UI.
By default, the UI is not included in the installation (except for docker images), and must be installed explicitly with `freqtrade install-ui`.
This same command can also be used to update freqUI, should there be a new release.
Once the bot is started in trade / dry-run mode (with `freqtrade trade`) - the UI will be available under the configured port below (usually `http://127.0.0.1:8080`).
!!! info "Alpha release"
FreqUI is still considered an alpha release - if you encounter bugs or inconsistencies please open a [FreqUI issue](https://github.com/freqtrade/frequi/issues/new/choose).
!!! Note "developers"
Developers should not use this method, but instead use the method described in the [freqUI repository](https://github.com/freqtrade/frequi) to get the source-code of freqUI.
By default, the configuration listens on localhost only (so it's not reachable from other systems). We strongly recommend to not expose this API to the internet and choose a strong, unique password, since others will potentially be able to control your bot.
If you're running on a VPS, you should consider using either a ssh tunnel, or setup a VPN (openVPN, wireguard) to connect to your bot.
This will ensure that freqUI is not directly exposed to the internet, which is not recommended for security reasons (freqUI does not support https out of the box).
Setup of these tools is not part of this tutorial, however many good tutorials can be found on the internet.
Also change `jwt_secret_key` to something random (no need to remember this, but it'll be used to encrypt your session, so it better be something unique!).
By using `8080:8080` in the docker port mapping, the API will be available to everyone connecting to the server under the correct port, so others may be able to control your bot.
By default, the script assumes `127.0.0.1` (localhost) and port `8080` to be used, however you can specify a configuration file to override this behaviour.
The API Server includes a websocket endpoint for subscribing to RPC messages from the freqtrade Bot.
This can be used to consume real-time data from your bot, such as entry/exit fill messages, whitelist changes, populated indicators for pairs, and more.
This is also used to setup [Producer/Consumer mode](producer-consumer.md) in Freqtrade.
Once connected to the WebSocket, the bot will broadcast RPC messages to anyone who is subscribed to them. To subscribe to a list of messages, you must send a JSON request through the WebSocket like the one below. The `data` key must be a list of message type strings.
Now anytime those types of RPC messages are sent in the bot, you will receive them through the WebSocket as long as the connection is active. They typically take the same form as the request:
There are some quirks when using a reverse proxy with the message websocket endpoint. The message websocket endpoint keeps a long-running connection open between the Rest API and the client. It's built on top of HTTP and uses the HTTP Upgrade mechanism to change from HTTP to WebSockets during connection. There are some challenges that a reverse proxy faces when supporting WebSockets, such as WebSockets are a hop-by-hop protocol, so when a proxy intercepts an Upgrade request from the client it needs to send it's own Upgrade request to the server, including appropriate headers. Also, since these connections are long lived, the proxy needs to allow these connections to remain open.
When using Nginx, the following configuration is required for WebSockets to work:
```
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
```
To configure your reverse proxy, see it's documentation for proxying websockets.
- **Traefik**: Traefik supports websockets out of the box, see the [documentation](https://doc.traefik.io/traefik/)
- **Caddy**: Caddy v2 supports websockets out of the box, see the [documentation](https://caddyserver.com/docs/v2-upgrade#proxy)
The below should be done in an application (a Freqtrade REST API client, which fetches info via API), and is not intended to be used on a regular basis.
This whole section is only necessary in cross-origin cases (where you multiple bot API's running on `localhost:8081`, `localhost:8082`, ...), and want to combine them into one FreqUI instance.
In the following (pretty common) case, FreqUI is accessible on `http://localhost:8080/trade` (this is what you see in your navbar when navigating to freqUI).
The correct configuration for this case is `http://localhost:8080` - the main part of the URL including the port.
SSL/TLS is used to provide security and encrypt network traffic. Freqtrade does not directly support SSL, but you can easily accomplish this with a reverse proxy such as Nginx or Traefik. Below are some steps to help you get started on setting one up for your bot. For the sake of simplicity, we will use a native installation of Nginx and certbot.
**Prerequisites**
Before starting this tutorial, you will need a few things.
- A Freqtrade bot set up and running
- A registered domain name, e.g. myftbot.com
- A DNS A record for the top level domain pointing to your server's public IP
**Step 1: Installing Nginx and Certbot**
Once you have all of the prerequisites, the first step is to get Nginx installed on your system. This tutorial assumes the use of Ubuntu 20.04, though you can find your linux distro's package commands via a search engine. First, update your local package index so that you have access to the most recent package listings then install Nginx:
``` bash
> sudo apt update
> sudo apt install nginx
```
After accepting the installation, Nginx and any dependencies will be installed to your system and automatically started. You can check it is running with `systemd`:
``` bash
> sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
├─1107 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─1108 nginx: worker process
├─1109 nginx: worker process
├─1110 nginx: worker process
└─1111 nginx: worker process
```
Next you need to install certbot which will handle all of the certificate automation for your web server and domain. To install certbot it is required to have `snapd` on Ubuntu. If you haven't installed it yet, please review the instructions on [snapcraft's site for installation](https://snapcraft.io/docs/installing-snapd/).
Once you are good to go, ensure your snapd version is up to date:
``` bash
> sudo snap install core; sudo snap refresh core
```
If you have any Certbot packages installed via your package manager, you should remove them before installing Certbot:
``` bash
> sudo apt remove certbot
```
Finally, install Certbot and prepare the Certbot command.
``` bash
> sudo snap install --classic certbot
> sudo ln -s /snap/bin/certbot /usr/bin/certbot
```
**Step 2: Adjust the firewall**
The next step is to allow HTTP and HTTPS traffic through your firewall. This is different for each depending on which firewall you use, and how you have it configured. In this example, we are using `ufw`.
We'll start by enabling `ufw` if it isn't already:
``` bash
> sudo ufw enable
```
You can list the application configurations that ufw knows how to work with
``` bash
> sudo ufw app list
Available applications:
CUPS
Nginx Full
Nginx HTTP
Nginx HTTPS
```
As you can see in the output, there are 3 profiles available for Nginx:
- **Nginx Full**: This profile opens both port 80 (normal web traffic) and port 443 (SSL/TLS traffic)
- **Nginx HTTP**: This profile only opens port 80 (normal web traffic)
- **Nginx HTTPS**: This profile only opens port 443 (SSL/TLS traffic)
We will configure the firewall to allow both port 80 and 443:
``` bash
> sudo ufw allow 'Nginx Full'
```
You can verify the change by typing:
``` bash
> sudo ufw status
Status: active
To Action From
-- ------ ----
Nginx HTTPS ALLOW Anywhere
Nginx Full ALLOW Anywhere
Nginx HTTPS (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)
```
**Step 3: Configuring Nginx**
Using your favorite editor, edit the default nginx configuration. In our case, it'll be under `/etc/nginx/conf.d/default.conf`:
``` bash
> sudo vim /etc/nginx/conf.d/default.conf
```
Add a section to your configuration like this:
```
server {
server_name myftbot.com;
location / {
proxy_pass http://localhost:8080;
}
}
```
Make sure to change `localhost` and `8080` to what you have set in your `api_server` configuration for your bot.
Verify your nginx config file syntax and make sure there are no errors:
``` bash
> sudo nginx -t
```
Finally you can reload nginx to get the new configuration changes:
``` bash
> sudo systemctl reload nginx
```
!!! Note
The `reload` command forces Nginx to read the new configuration without interrupting any connections. The `restart` command restarts the whole nginx service.
**Step 4: Getting the certificates**
Certbot already comes with an easy way to setup Nginx with SSL/TLS th automatically changes your configuration file with the required fields:
``` bash
> sudo certbot --nginx
```
You will be prompted for some information such as your email (To receive updates about your certificates), the domain you pointed to the server, and agree to the TOS and optional newsletter. You can also set to redirect HTTP traffic to HTTPS, removing HTTP access.
You can now test your SSL setup by using curl to make a request to your bot's Rest API:
