How to Deploy a Python Trading Bot on Ubuntu VPS

Automated trading systems need to run continuously, maintain a stable network connection, recover after failures, and remain available even when your local computer is turned off. A virtual private server is one of the simplest ways to provide this environment.

In this guide, we will deploy a Python trading bot on an Ubuntu VPS from scratch. We will prepare the operating system, create an isolated Python environment, configure exchange credentials, test the bot, run it as a background service, enable automatic startup, configure logging, and apply several basic security measures.

The same deployment approach can be used for cryptocurrency bots, market monitoring applications, algorithmic trading systems, arbitrage scripts, alert services, and other Python applications that need to operate continuously.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry

How a Python Trading Bot Works on a VPS

A trading bot usually consists of several components:

• Python application — contains the strategy and trading logic.
• Exchange or broker API — provides market data and allows the application to manage orders.
• Python libraries — provide API clients, data processing tools, indicators, logging, and other functionality.
• Configuration and API keys — store parameters required to connect to the trading platform.
• VPS — keeps the application running independently from your local computer.
• systemd — supervises the bot process and can restart it automatically if it stops unexpectedly.
• system journal — stores application output and errors for troubleshooting.

The final architecture will look approximately like this:

This architecture separates the trading application from your personal computer and provides a controlled Linux environment for continuous execution.

What You Need

Before starting, prepare:

• an Ubuntu VPS;
• SSH access to the server;
• a Python trading bot or Python project;
• an account with the exchange or broker used by the bot;
• API credentials if private API operations are required;
• basic knowledge of Linux terminal commands.

For a lightweight bot that processes several trading pairs, a small VPS is usually sufficient as a starting point.

These values are starting points rather than strict requirements. CPU and memory consumption depend heavily on the strategy, number of markets, frequency of requests, libraries, database usage, and amount of historical data processed.

Step 1. Deploy an Ubuntu VPS

Create a virtual server with Ubuntu installed.

For most Python projects, a current Ubuntu LTS release is a convenient choice because it provides stable package repositories and long-term security updates.

After deployment, you should receive:

• the public IP address of the VPS;
• a root password or configured SSH key;
• SSH access to the operating system.

It is preferable to use SSH key authentication instead of relying exclusively on passwords.

Step 2. Connect to the VPS via SSH

On Linux or macOS, open Terminal.

On modern Windows systems, SSH can also be used directly from PowerShell or Windows Terminal.

Connect to the server:

Replace:

with the actual public IP address of your VPS.

For example:

If you are connecting to the server for the first time, SSH may ask you to confirm the server fingerprint.

Type:

Then authenticate using your password or SSH key.

Step 3. Update Ubuntu

Before installing the application, update information about available packages:

Install available updates:

This reduces the chance of deploying the application on top of outdated system packages.

You can check the operating system version with:

or:

Step 4. Create a Dedicated User for the Trading Bot

Running an Internet-connected application permanently as `root` is unnecessary and increases the potential impact of a compromised process.

Create a separate system user:

We will use this account to own and execute the application files.

Create a directory for the project:

Give ownership to the new user:

The project will now be located at:

Step 5. Install Python and Required Tools

Install Python, virtual environment support, pip, Git, and curl:

Check the installed Python version:

Check Git:

Using a Python virtual environment is especially important on current Ubuntu installations because it keeps project dependencies separate from packages managed by the operating system.

Step 6. Create a Python Virtual Environment

Switch to the application user:

Move to the project directory:

Create a virtual environment:

Activate it:

The shell prompt should now contain something similar to:

Upgrade pip inside the virtual environment:

Packages installed while the environment is active will remain isolated from Ubuntu's system Python installation.

Step 7. Upload the Trading Bot

There are several ways to transfer your project to the VPS.

Option 1. Clone the Project from Git

If the project is stored in Git:

For an existing /opt/trading-bot directory, you can alternatively initialize or clone the repository into another directory and move the required files afterward.

For private repositories, use an SSH deploy key or another secure authentication mechanism instead of storing your personal account credentials directly on the server.

Option 2. Copy Files with SCP

From your local computer:

Option 3. Create the Script Directly on the VPS

For a small test project, create a file:

You can then paste your Python code into it.

Step 8. Install Python Dependencies

A production project should normally describe its dependencies in a requirements.txt file.

For example:

Install them:

For demonstration purposes, we will use CCXT, a Python library that provides a unified interface for many cryptocurrency exchange APIs.

You can also install the packages directly:

Check that CCXT can be imported:

Step 9. Create a Test Trading Bot

If you already have your own bot, you can skip this section.

Otherwise, create:

Add the following example:

This script does not place orders. It connects to the selected exchange, loads available markets, periodically requests ticker data, and writes the result to the log.

The parameter:

enables CCXT's built-in request throttling mechanism. Your application should still follow the limits and API rules imposed by the selected exchange.

For a real project, replace the monitoring section with your own strategy, order-management code, risk controls, database integration, or other application logic.

Step 10. Store Configuration and API Keys Separately

Do not hardcode API credentials directly inside bot.py.

Instead, create an environment file:

Add:

Replace the exchange, trading pair, and credentials with values required by your application.

For example, another exchange might use:

Save the file.

Exit back to the root user:

Change its ownership:

Restrict permissions:

Verify:

The file should not be readable by unrelated system users.

If you use Git, also make sure .env is excluded from the repository:

Never commit production API keys to a Git repository.

Deploy Your Trading Infrastructure on Serverspace

A trading bot does not require your personal computer to remain online when it runs on a cloud VPS. This is especially useful for strategies that monitor markets continuously, process scheduled signals, or communicate with trading APIs throughout the day.

With Serverspace, you can deploy an Ubuntu VPS and independently select the amount of CPU, RAM, and storage required by your application. This makes it possible to start with a lightweight configuration and increase resources later if the bot begins processing more markets, running additional workers, or storing larger datasets.

Serverspace also provides cloud infrastructure in multiple geographic locations, allowing you to choose a server location appropriate for your workload.

For Python applications, the VPS gives you full control over the environment: you can install your own Python packages, databases, monitoring tools, Docker containers, schedulers, and other components required by the trading system.

Deploy an Ubuntu VPS in Serverspace, connect through SSH, and use the steps below to turn your Python script into a continuously running service.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry

Step 11. Test the Bot Manually

Before configuring automatic startup, verify that the application works normally from the command line.

Run:

If the configuration is correct, the output should look similar to:

The actual price will depend on current market data.

Stop the application with:

Do not proceed to automatic startup until the bot works correctly when started manually.

Step 12. Configure the Bot as a systemd Service

Starting the script manually is useful during development, but the process will terminate if:

• the SSH session is closed incorrectly;
• the process crashes;
• the VPS reboots;
• the application encounters an unrecoverable error.

A better approach is to let `systemd` supervise the application.

Create a new service:

Add:

Let's examine the most important parameters.

User and Group

The application runs under the dedicated account instead of root

WorkingDirectory

Sets the project's working directory.

EnvironmentFile

Loads configuration variables before the process starts.

ExecStart

Uses Python directly from the project's virtual environment.

Restart

Tells systemd to restart the application when the process terminates because of a failure.

RestartSec

Adds a delay before another startup attempt.

This is particularly useful for applications that depend on external APIs because immediately restarting a failed process in a tight loop can create unnecessary requests.

Step 13. Enable Automatic Startup

Tell systemd to reload unit files:

Enable the trading bot at system startup:

Start it:

Check the service:

A successful service normally shows:

You can also perform both operations at once:

Step 14. View Trading Bot Logs

Because the process is managed by `systemd`, its standard output and errors can be inspected through journalctl.

Display the latest messages:

Follow the logs in real time:

Display messages generated since the beginning of the current day:

Show the latest 100 entries:

Show only errors:

This is usually the first place to check if the service has stopped or cannot connect to an external API.

Press:

to leave real-time log monitoring.

Step 15. Test Automatic Recovery

It is useful to verify that systemd actually supervises the process.

Find the current Python process:

You should see something similar to:

Terminate the process:

Replace 12345 with the actual PID.

Wait several seconds and check:

Because the service contains:

systemd should start a new process after the configured delay.

You can inspect this event using:

Step 16. Test Startup After a VPS Reboot

Another important test is a complete server restart.

Reboot Ubuntu:

Your SSH connection will close.

Wait until the VPS becomes available again and reconnect:

Check:

If everything has been configured correctly, the application should already be running.

Step 17. Configure the Firewall

A trading bot that only makes outgoing HTTPS or WebSocket connections normally does not need to expose its own public application port.

If you use UFW, first allow SSH:

Then enable the firewall:

Check the configuration:

If your SSH daemon uses a custom port instead of the standard configuration, create the appropriate firewall rule before enabling UFW.

For example:

Do not blindly expose application, database, monitoring, or administration ports to the entire Internet.

If your bot includes a dashboard or API, consider binding it to localhost and accessing it through an SSH tunnel or placing it behind an authenticated reverse proxy.

Step 18. Check Server Time Synchronization

Correct system time is important for applications communicating with trading APIs. Authentication mechanisms frequently depend on timestamps, and a significant clock difference can cause API requests to fail.

Check the server clock:

Look for synchronization information.

If network time synchronization needs to be enabled:

Check again:

Application logic should generally store timestamps internally in a consistent timezone, often UTC, and convert them to local time only when displaying information to users.

Step 19. Protect Exchange API Keys

API credentials are one of the most sensitive components of a trading server.

Follow several important rules:

• never store API secrets directly in the source code;
• never commit .env files to Git;
• restrict filesystem permissions;
• create separate API credentials for the bot;
• enable only the permissions that the bot actually requires;
• avoid withdrawal permissions unless they are absolutely necessary;
• use IP restrictions if your exchange provides them;
• rotate compromised credentials immediately;
• do not send API keys through public chats, issue trackers, or screenshots.

For a bot that only collects public market data, API credentials may not be necessary at all.

For live trading, the key usually needs trading permissions, but allowing withdrawals significantly increases the consequences of credential theft.

Step 20. Secure SSH Access

SSH keys provide a stronger server access model than reusable passwords.

Generate a key on your local computer if you do not already have one:

Copy the public key to the VPS:

Confirm that key-based login works before changing SSH authentication settings.

You can then edit:

Common hardening options include:

However, disable root and password authentication only after creating another administrative user with working SSH key access. Otherwise, you may lock yourself out of the server.

Validate the SSH configuration before restarting the service:

If no errors are returned, restart SSH:

Keep your current SSH session open while testing a second connection.

Step 21. Updating the Trading Bot

Applications and dependencies will eventually need updates.

If the project is stored in Git, switch to the application account:

Go to the project:

Download the latest changes:

Activate the environment:

Update dependencies:

Exit:

Restart the application:

Verify:

Then inspect logs:

For important production systems, test updates in a separate environment before deploying them to the live server.

Step 22. Pin Python Dependency Versions

Installing the newest versions of every package during each deployment can produce unexpected behavior when upstream libraries introduce changes.

After testing your environment, record installed versions:

A resulting file might contain entries such as:

The actual versions depend on the environment at the time the command is executed.

Pinned dependencies make deployment more reproducible because another server can install the same package versions.

Do not update production dependencies automatically without testing them first.

Step 23. Monitor CPU and Memory Usage

Check current resource consumption:

or:

If htop is not installed:

Run:

You can also inspect memory:

Disk usage:

And system load:

A lightweight trading bot may consume very few resources, while applications performing large pandas calculations, technical indicator analysis, machine-learning inference, backtesting, or processing hundreds of markets can require considerably more CPU and RAM.

Step 24. Monitor Disk Space

Trading applications can unexpectedly consume disk space if they continuously store:

• market data;
• candles;
• order books;
• trade history;
• application logs;
• database files;
• backtesting datasets.

Check disk usage:

Find large project directories:

If your application writes its own log files instead of using the system journal, configure log rotation so they do not grow indefinitely.

Step 25. Using a Database with the Trading Bot

A more advanced bot may need persistent storage for:

• historical prices;
• generated signals;
• orders;
• positions;
• strategy state;
• performance statistics;
• error information.

Small applications can use SQLite.

More complex systems may use PostgreSQL or another database server.

A typical architecture might look like:

Avoid exposing a database directly to the public Internet unless there is a specific reason to do so.

If the database and trading bot run on the same VPS, the database can normally listen only on localhost.

Step 26. Running Multiple Trading Bots

You can operate several independent bots on the same VPS.

For example:

Each application can have:

• its own virtual environment;
• its own .env file;
• its own systemd service;
• its own exchange credentials;
• its own logs and configuration.

Corresponding services might be:

Check them independently:

and:

This is generally easier to maintain than placing unrelated strategies inside one large process.

Step 27. Add Health Monitoring

systemd can restart a crashed application, but it cannot always determine whether the trading logic itself is functioning correctly.

For example, a Python process could remain alive while:

• API requests continuously fail;
• market data stops updating;
• a WebSocket connection becomes stale;
• the database becomes unavailable;
• the strategy loop becomes blocked;
• credentials expire or are revoked.

For production workloads, consider adding application-level health monitoring.

The bot can periodically report:

• last successful API request;
• last received market update;
• current exchange connection state;
• open positions;
• last completed strategy cycle;
• database status;
• memory consumption;
• error count.

Notifications can be delivered to an external monitoring platform, email, Telegram, Slack, or another communication system.

The important principle is that the monitoring mechanism should be independent enough to notify you when the bot itself is unable to do so.

Recommended Production Directory Structure

As the application grows, keeping the project organized becomes increasingly useful.

For example:

The exact structure is project-specific, but separating exchange communication, strategy logic, configuration, storage, and notifications makes the application easier to test and maintain.

Common Trading Bot Deployment Problems

Useful Commands for Managing the Bot

Check status:

Start:

Stop:

Restart:

Enable startup after reboot:

Disable automatic startup:

Follow logs:

Show the latest 100 log entries:

Reload a modified systemd configuration:

Production Checklist

Before connecting the bot to a live trading account, verify the entire deployment.

• The bot runs under a dedicated Linux user.
• The project uses a Python virtual environment.
• Dependencies are documented and preferably pinned.
• API credentials are not stored in source code.
• The .env file has restricted permissions.
• API keys have only the permissions actually required.
• Withdrawal permissions are disabled unless specifically required.
• The strategy has been tested separately from production.
• API and network errors are handled by the application.
• The bot respects exchange request limits.
• The process is managed by systemd.
• Automatic restart has been tested.
• Automatic startup after server reboot has been tested.
• Logs can be inspected with journalctl.
• System time is synchronized.
• SSH access is secured.
• Unnecessary network ports are closed.
• CPU, RAM, and disk consumption are monitored.
• There is an independent way to detect application failures.

A technically running process should not automatically be considered a healthy trading system. Production monitoring should also verify that new market data is arriving, API calls succeed, strategy cycles complete, and application state remains consistent.

Conclusion

Deploying a Python trading bot on an Ubuntu VPS transforms a local script into a continuously running server application.

The basic production workflow consists of creating an Ubuntu server, installing Python, isolating dependencies inside a virtual environment, transferring the project, protecting API credentials, testing the application manually, and moving the process under systemd.

From there, the infrastructure can evolve with the project. You can add PostgreSQL, Redis, Docker, monitoring systems, notifications, backup processes, multiple strategies, or separate services for market data and order execution.

The VPS solves an important operational problem: the trading application no longer depends on your laptop, home Internet connection, or an open terminal session. However, reliable infrastructure does not make a trading strategy profitable and does not eliminate market, API, software, or operational risks.

Run Your Python Trading Bot on Serverspace

Serverspace provides Ubuntu cloud servers suitable for hosting continuously running Python applications, including trading bots, market monitoring tools, API integrations, and data-processing services.

You can choose the required vCPU, RAM, and storage configuration when deploying the VPS and adjust the infrastructure as the project grows. A lightweight bot can start with a small virtual machine, while more demanding systems can use additional computing resources for multiple strategies, databases, analytics, or large datasets.

The cloud environment also gives you full administrative access, so you are free to configure Python, systemd, Docker, PostgreSQL, Redis, monitoring software, or any other components required by your application.

Instead of keeping a trading script running on a personal computer, deploy an Ubuntu VPS on Serverspace and create a dedicated environment that can operate independently around the clock.

Create your Serverspace cloud server, deploy Ubuntu, connect via SSH, and use this guide to bring your Python trading bot online.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry

Frequently Asked Questions (FAQ)