Start checklist: what you need before your first server

Before you install the panel and nodes, you have to get the server in order and make sure the foundation isn't rotten. Below is a short route of checks and basic host hardening. Copy the commands in order and enter your own data in the builder above.

This material covers the engineering of your own network infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is on you.

Before you buy: a short check

Even before paying for a VPS, run yourself down the list — these four points catch 90% of future problems:

1. Node — abroad (NL/DE/FI/PL), panel and relay — Russia is fine.
2. Different ASNs for different nodes — blocking is done in batches by subnet.
3. White IP — not on blacklists, not in a flagged proxy subnet.
4. Payment — wherever possible, crypto or SBP without extra ties.

The mechanics of each point were covered in the theory "How to choose a server." Here it's the practice of checking one you've already bought.

Checking the domain's DNS

If you're installing a panel or a node with a domain, first make sure the A record actually points to the server's IP. Until DNS resolves, the TLS certificate won't be issued, and going further is pointless:

# should return your server's IP, and nothing else
dig +short your-domain.com

Empty or a stranger's address — fix the A record at the registrar and wait for propagation. DNS first, everything else after. This rule will save you an hour of rage at the certificate-issuing stage.

Getting the system in order

Log into the fresh server and set up the basics. Ubuntu 22.04 or 24.04 is a solid choice:

# update the system
apt update && apt -y upgrade

# the basic kit: firewall, brute-force protection, utilities
apt -y install ufw fail2ban curl git nano

SSH by key only

An SSH password is an open door for brute-forcing. Switch login to key-based. First on your own machine, if you don't have a key yet:

# generate a key and put it on the server
ssh-keygen -t ed25519 -C "vpn-admin"
ssh-copy-id root@SERVER_IP

Now on the server, disable password login entirely:

sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
systemctl restart ssh

Verify the new login works without closing your current session — if something's wrong, you'll have time to roll back. Close it while the key hasn't been picked up, and you'll be locked out.

Firewall: close everything unnecessary

By default drop all incoming, open only what's needed. For the panel and nodes, 443 faces outward; for management, SSH:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 443/tcp        # nodes/panel behind 443
ufw --force enable

Additional ports for transports (gRPC, XHTTP, node agent) you'll open later, when configuring a specific node. For now — the minimum.

Protection against SSH brute-force

fail2ban bans an IP that hammers with passwords. Set up a jail for sshd:

systemctl enable --now fail2ban
cat >/etc/fail2ban/jail.d/sshd.local <<'CFG'
[sshd]
enabled = true
maxretry = 4
bantime = 1h
findtime = 10m
CFG
systemctl restart fail2ban

Four misses in ten minutes — a one-hour ban. For key-based login that's more than enough.

Network tuning for nodes

On nodes (not the panel) enable BBR — it noticeably improves speed on long routes, which is exactly what a foreign exit to Russia has:

cat >>/etc/sysctl.conf <<'CFG'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
CFG
sysctl -p

Check that it applied:

# should print: bbr
sysctl net.ipv4.tcp_congestion_control | awk '{print $NF}'

Final check before the panel

A run-through of host readiness — if every point is green, you can install the panel:

# key-based login, password disabled
grep -E '^(PasswordAuthentication|PermitRootLogin)' /etc/ssh/sshd_config

# firewall on and rules in place
ufw status verbose

# fail2ban alive
systemctl is-active fail2ban

All good — the foundation is ready. Next you head to the "Panel" section and install Remnawave on this server. Remember the separation rule: panel and nodes on different machines, so you'll repeat this basic prep on every server separately. The mechanics of why each step is needed were covered in the theory "How to choose a server and location."