Step 1: Create the VPS

Create a new Linux VPS with the provider you have selected.

Choose the operating system required by the current Spider DCA Bot release.

Record the server IP, provider region, server name, operating system and assigned CPU, RAM and storage.

If your provider offers a network-level firewall or security group, enable it.

That provides another defensive layer in addition to the firewall inside Ubuntu.

Step 2: Connect to the VPS Using SSH

SSH is the normal secure remote-administration method for an Ubuntu server.

OpenSSH provides encrypted remote access and supports public-key authentication.

The basic connection format is:

ssh USERNAME@SERVER_IP

Your VPS provider will tell you the initial username.

Do not assume it is always root. Some cloud providers create a default non-root account instead.

Why SSH Keys Are Preferable

A strong SSH key allows authentication without repeatedly using a reusable account password.

The private key remains on your trusted computer. The VPS receives only the public key.

Step 3: Create a Non-Root Administration User

If your VPS provider gives you initial root access, create a separate administration account for normal server work.

For example:

sudo adduser spideradmin
sudo usermod -aG sudo spideradmin

The exact username is your choice.

Install your SSH public key for that account.

Then open a second terminal window and confirm that the new account works before changing root or password-based SSH settings.

This small step can save you from locking yourself out of the VPS.

Do Not Disable Password Access Too Early

A common mistake is to change SSH authentication settings before testing the new SSH key.

1. Change SSH configuration.
2. Disable password or root login.
3. Reload SSH.
4. Discover the new key was never installed correctly.

Test key authentication first.

Before reloading SSH after configuration changes, validate the configuration:

sudo sshd -t

If the command reports an error, correct the configuration before reloading the SSH service.

Step 4: Update the Server

A new VPS image may already have security updates waiting.

Start with:

sudo apt update
sudo apt upgrade -y

Ubuntu also provides unattended-upgrades for automatic
security updates.

Check whether it is installed:

dpkg -l | grep unattended-upgrades

If needed:

sudo apt install unattended-upgrades

Step 5: Configure the VPS Firewall

A server should not make every listening service reachable from the
internet.

Ubuntu commonly uses UFW, or Uncomplicated Firewall, as a host firewall
interface.

A simple starting policy can be:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH

If you deliberately serve a public website through HTTP and HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Then:

sudo ufw enable
sudo ufw status verbose

Do Not Blindly Open Database Ports

The public internet normally should not need direct access to services such as:

• PostgreSQL
• Redis
• ClickHouse
• internal APIs
• worker ports
• Docker daemon

Internal services should stay on private container networks, localhost or an appropriately protected private network wherever the architecture allows.

Important Docker and UFW Warning

In practical terms:

“UFW says this port is closed” does not automatically prove that a Docker-published port is unreachable.

Do not publish internal Spider services to 0.0.0.0 unless they genuinely require public access.

Step 6: Install Docker and Docker Compose

If the current Spider release uses Docker and Docker Compose, containers provide a consistent way to run several related application services.

Do not mix different Docker installation methods carelessly.

Follow Docker’s current official installation instructions for the Ubuntu version running on your VPS.

After installation, verify Docker:

sudo docker version
sudo docker compose version

Check the service:

sudo systemctl status docker

Be Careful With the Docker Group

Many tutorials recommend adding a user to the Docker group so Docker commands can run without sudo:

sudo usermod -aG docker USERNAME

Step 7: Create a Dedicated Application Directory

Keep the trading application organized instead of scattering files across the server.

For example:

sudo install -d -m 0750 -o spideradmin -g spideradmin /opt/spider-dca

Then:

cd /opt/spider-dca

A predictable application directory helps with updates, backups, permissions, troubleshooting and disaster recovery.

Step 8: Obtain Spider DCA Bot

At this stage you need the actual Spider DCA Bot software.

This is where a generic server tutorial should stop guessing.

Use only the official distribution method.

That may be:

• a private repository;
• a release archive;
• a deployment package;
• an installer;
• or another approved delivery method.

Watch the Spider DCA Bot VPS installation video

Avoid “curl | bash” Without Review

One-line installers are convenient, but convenience should not override security.

If an installer downloads a remote script and immediately runs it with elevated privileges, verify its official source and understand what the script does before execution.

Step 9: Configure Environment Variables and Secrets

A trading platform may require configuration for database credentials, encryption keys, authentication secrets, domains, email, exchanges, service URLs and runtime modes.

Never hard-code secrets into application source code.

Never commit a real .env file into Git.

If a local .env file is required, restrict its permissions:

umask 077
touch .env
chmod 600 .env

Use Placeholder Values in Tutorials

APP_SECRET=GENERATE_A_REAL_SECRET
DATABASE_PASSWORD=CREATE_A_STRONG_PASSWORD

Do not replace those example values with real production credentials in screenshots or public documentation.

Environment Variables Are Not a Perfect Secret Vault

Sensitive environment values can sometimes be exposed through processes, debugging output or logs.

Docker Compose also supports secrets, which can provide more granular per-service secret access when the application supports that design.

Step 10: Configure the Domain and HTTPS

If you access Spider DCA Bot from a browser over the internet, do not serve the login or trading interface over plain HTTP.

Use HTTPS.

Common reverse-proxy options include Nginx, Caddy, Traefik and managed cloud proxies.

Use the solution that matches the current Spider deployment.

VERIFY CURRENT SPIDER DCA BOT REVERSE PROXY

Reduce Public Exposure Where Possible

If only you need access to the dashboard, consider whether it needs to be globally reachable from every internet address.

Possible controls include:

• source-IP restrictions;
• VPN-only access;
• Zero Trust access controls;
• or another authenticated private-access layer.

Step 11: Start Spider DCA Bot

The exact deployment command must match the current Spider release.

Do not substitute an invented command.

CHECK THE SPIDER DCA BOT START COMMAND FROM INSTALLATION VIDEO 

If Spider uses Docker Compose, common operational commands include:

sudo docker compose ps

To inspect recent logs:

sudo docker compose logs --tail=100

To follow new logs:

sudo docker compose logs -f

Exit the live log stream with:

Ctrl + C

This normally stops following the output. It does not stop the running containers.

Avoid Logging Secrets

Before sharing logs publicly or sending them to support, inspect them and remove:

• API keys;
• tokens;
• private email addresses;
• cookies;
• authorization headers;
• internal secrets;
• database connection strings.

Step 12: Verify Every Service

Do not assume the installation succeeded merely because one webpage loads.

A multi-service trading platform can have a working frontend while an important backend dependency is failing.

Check:

• application containers and services;
• database health;
• web and API responses;
• background workers;
• exchange connectivity;
• market-data freshness;
• authentication;
• WebSocket connectivity where applicable;
• Bot Engine status;
• available disk space;
• system memory.

Check disk usage:

df -h

Check memory:

free -h

Check system uptime and load:

uptime

For a Docker Compose deployment:

sudo docker compose ps

Step 13: Confirm Restart Behaviour

A trading application should not require a person to SSH into the VPS after every normal reboot simply to restart all services manually.

Docker Compose supports restart policies, and production deployments commonly configure suitable restart behavior.

Do not blindly edit Spider’s Compose files.

First confirm the restart behavior already defined by the application.

VERIFY SPIDER DCA BOT RESTART POLICY using pm2

During a safe testing window, perform a controlled reboot:

sudo reboot

Reconnect after the server returns.

If Compose is used, check:

sudo docker compose ps

Step 14: Open Spider DCA Bot in the Browser

Once the platform is healthy and HTTPS or other access controls are correct, open the Spider interface.

Do not invent default login credentials.

Follow the actual bootstrap process for the current build.

VERIFY CURRENT SPIDER DCA BOT FIRST-LOGIN WORKFLOW FROM THE VIDEO

After login, inspect the high-level dashboard before creating a bot.

The supplied Spider interface includes areas for:

• system status;
• DCA bots;
• exchange management;
• bot runtime;
• risk controls;
• engine monitoring.

Step 15: Secure the Spider Account

Server security is only one layer.

Protect the Spider account itself with:

• a strong unique password;
• MFA where supported;
• a protected email account;
• secure recovery methods;
• minimum required privileges.

The supplied Spider interface includes MFA-related security controls. Configure MFA for the owner or administrator account before high-risk operations.

Step 16: Connect an Exchange Carefully

After installation, exchange connectivity is one of the next practical tasks.

The Spider software includes an Exchange area for managing connections and readiness.

Use Minimum API Permissions

An exchange API key can authorize sensitive financial actions.

Treat it with the same seriousness as other important account credentials.

Use an IP Allowlist Where Supported

A VPS normally has a stable public IP address.

Some exchanges let you restrict an API key so requests are accepted only from specified IP addresses.

Use IP restrictions where supported and appropriate for your deployment.

Step 17: Start With Paper Mode

A successful installation is not a reason to start live
trading immediately.

The supplied Spider DCA Bot creation interface provides a visible choice
between PAPER and LIVE.

Use Paper mode first.

Paper testing can help verify:

• bot creation;
• Start, Pause and Stop behaviour;
• exchange and market-data connectivity;
• averaging-order logic;
• risk gates;
• alerts;
• runtime logs;
• command processing;
• restart recovery.

Paper trading still cannot perfectly reproduce live execution.

Real trading introduces factors such as liquidity, slippage, partial
fills, exchange delays, fees and operational mistakes involving actual
capital.

Step 18: Verify the Bot Engine Before Trading

Spider DCA Bot includes a Bot Engine Control Center.

This matters because a healthy webpage does not automatically mean the
execution engine is healthy.

Step 19: Create the First DCA Bot

Once the server and application are healthy, move to strategy configuration.

My separate Spider DCA Bot software walkthrough covers this stage in more detail:

Complete Spider DCA Bot Software Walkthrough

At minimum, understand:

• trading pair;
• base order;
• committed capital;
• safety and averaging orders;
• price deviation;
• order-size scaling;
• maximum exposure;
• take profit;
• stop-loss and risk rules;
• entry conditions;
• Paper vs Live mode.

Step 20: Monitor the VPS After Installation

“Running” is not enough.

You need to know when something stops running or begins operating incorrectly.

Disk Usage

df -h

A full disk can break databases, logs, updates, container downloads and backups.

Memory

free -h

If services repeatedly exhaust memory, investigate the cause and increase resources if necessary.

Containers

sudo docker compose ps

Logs

sudo docker compose logs --tail=100

Application Health

Use Spider’s operational dashboards and Bot Engine monitoring rather than relying only on Linux process status.

A container can technically be running while its exchange connection or internal processing is unhealthy.

Step 21: Do Not Ignore Server Time

Trading APIs frequently use timestamps as part of request authentication.

A server with seriously incorrect time can cause authentication failures or signed-request errors.

Check time status with:

timedatectl

Look for synchronization status.

Do not manually change the server clock randomly while troubleshooting. First determine whether clock drift is actually the problem.

Step 22: Back Up the Trading Bot Properly

A VPS is not a backup.

If the server filesystem is deleted, damaged or compromised, data stored only on that server may disappear.

Identify what Spider DCA Bot requires for recovery.

That may include:

• database data;
• configuration;
• application state;
• uploaded files;
• encryption material;
• certificates;
• operational evidence;
• selected logs.

VERIFY SPIDER DCA BOT OFFICIAL BACKUP PROCEDURE IN THE VIDEO

Protect Backup Copies

Server snapshots and archives may contain database passwords, authentication secrets, API credentials and environment files.

Treat backup files as sensitive data.

Encrypt them where appropriate and restrict who can access them.

Step 23: Test Restore, Not Just Backup

A backup you have never restored is only an assumption.

Periodically verify that recovery actually works.

A useful restore test answers:

• Is the backup readable?
• Is the database complete?
• Are required encryption keys available?
• Can the application start?
• Are user accounts and authentication intact?
• Are critical settings preserved?

Perform restoration tests in a separate controlled environment rather than placing the live VPS at unnecessary risk.

Step 24: Updating Spider DCA Bot Safely

Do not update production trading software like an ordinary blog plugin.

Before an update:

1. Read the release notes.
2. Check migration requirements.
3. Verify compatible versions.
4. Create a backup.
5. Understand rollback.
6. Pause trading if required.
7. Check for uncertain execution states.
8. Apply the update.
9. Inspect logs.
10. Verify application health.
11. Test important workflows.

An application update may include database migrations, container changes, configuration changes, dependency updates or breaking changes.

Step 25: Why Restart Policies Matter

A VPS can remain healthy while one application process crashes.

Without restart management, that service could remain offline indefinitely.

Docker Compose supports service restart behavior for appropriate production workloads.

However, automatic restart has limits.

If a service continuously fails because of a configuration error, restarting it repeatedly can hide the actual problem.

Combine restart behaviour with:

• health checks;
• monitoring;
• alerts;
• logs;
• sensible retry rules.

Step 26: Docker Secrets and Configuration Security

Trading software eventually handles credentials that can authorize financial actions.

Avoid placing secrets in:

• Dockerfiles;
• Git repositories;
• frontend JavaScript;
• screenshots;
• command history where practical;
• public CI logs;
• support messages.

Docker Compose supports secret handling when applications are designed to use it.

Spider DCA Bot should follow the secret-management system supported by the current application release.