A new VPS is scanned by bots within minutes of getting a public IP address. Open the log of a fresh server and you will already see hundreds of failed root logins. None of this is dangerous if you spend ten minutes on setup first. Here is the short checklist I use on every new server.

1. Create a normal user

Do not work as root. Create a user and give it sudo rights:

adduser deploy
usermod -aG sudo deploy

2. Log in with a key, not a password

On your own computer, create a key (skip this if you already have one):

ssh-keygen -t ed25519 -C "my-laptop"
ssh-copy-id deploy@YOUR_SERVER_IP

Open a second terminal and check that ssh deploy@YOUR_SERVER_IP logs you in without asking for the account password. Keep the first session open until this works. It is your safety net.

3. Turn off root and password logins

Create the file /etc/ssh/sshd_config.d/hardening.conf with these lines:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3

Check the config and reload:

sudo sshd -t && sudo systemctl reload ssh

If sshd -t prints nothing, the syntax is fine. Test a new login from a second terminal before closing the first one.

4. Enable a firewall

With UFW you allow only what you really need (open 80 and 443 only if you run a website):

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable

5. Add Fail2ban

Fail2ban bans IP addresses that keep failing to log in:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

The defaults already protect SSH. Check it with sudo fail2ban-client status sshd.

6. Keep the system updated

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Security patches then install by themselves.

Should you change the SSH port?

Moving SSH from 22 to another port reduces log noise, but it is not real security. Keys and a firewall do the real work. If you change the port, open the new port in the firewall before you reload SSH, otherwise you lock yourself out.

What if you lock yourself out?

It happens to everyone once. Most providers give you a web console or a rescue mode that does not depend on SSH. Before you start, find where that is in your control panel, so you know it exists.

Summary

A normal user, key-only login, no root over SSH, a firewall and Fail2ban stop almost all automated attacks. It takes ten minutes, and you only do it once per server.

A longer version with explanations is in our guide: https://buran.host/guides/ssh-hardening

If you are looking for a server to practice on, our plans start here: https://buran.host/vps

Vaultwarden is a lightweight Rust implementation of the Bitwarden server. It works with all the official clients (browser extensions, iOS/Android and desktop apps), and the vault is a single directory with SQLite on your own server. It uses roughly 100–200 MB of RAM, so even the smallest plan is enough.

1. Firewall and directory

apt update && apt install -y ufw
ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp && ufw --force enable
mkdir -p /opt/vaultwarden/data && cd /opt/vaultwarden
echo "ADMIN_TOKEN=$(openssl rand -base64 48)" > .env   # save this token

Docker must be installed (on Ubuntu: curl -fsSL https://get.docker.com | sh).

2. docker-compose.yml

services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    env_file: .env
    environment:
      - DOMAIN=https://vault.example.com
      - SIGNUPS_ALLOWED=true
      - WEB_VAULT_ENABLED=true
    ports:
      - "127.0.0.1:8085:80"
    volumes:
      - ./data:/data

The port is bound to 127.0.0.1 only: the service reaches the internet through Caddy. Start it with docker compose up -d.

3. HTTPS with Caddy

Point an A record for vault.example.com at your server's IP first. Then:

apt install -y caddy
cat > /etc/caddy/Caddyfile <<'EOF'
vault.example.com {
    reverse_proxy 127.0.0.1:8085
}
EOF
systemctl reload caddy

Caddy obtains and renews the Let's Encrypt certificate by itself.

4. Close registration

Open https://vault.example.com, create your account and immediately change SIGNUPS_ALLOWED=true to false in docker-compose.yml, then run docker compose up -d again. Otherwise anyone who finds the address can create an account on your server.

The admin panel lives at /admin. Here the token is stored in plain form: that is acceptable for a personal server, but the project recommends storing an Argon2 hash in ADMIN_TOKEN (generated with the vaultwarden hash command) if you keep the admin panel enabled.

5. Connect your clients

In any Bitwarden client, choose Self-hosted on the login screen and enter https://vault.example.com. After that, sign in as usual.

6. Backups — do not skip this

The whole vault is the ./data directory. Keep a copy outside this server: for example an encrypted restic repository on a nightly systemd timer. A copy on the same disk will not save you if the server itself is lost. Test the restore: a backup you have never restored is a hope, not a backup.

What you get

Your own password server: your domain, your disk, updates in your hands. The one honest downside: administration is now your job — image updates, backups, monitoring.

A longer version with FAQ: https://buran.host/guides/vaultwarden-vps

If you've ever had a card declined by a hosting provider — or simply don't want to hand over a passport to rent a Linux box — paying in crypto is a practical alternative. Here is how it works end to end, and the mistakes that actually cost people money.

1. Pick a plan and open an invoice

Choose a server, click "Order" and register with an email address you really read: the invoice, the login details and all renewal reminders go there. The invoice shows an exact amount and a payment address.

2. Pick the coin — and the right network

Send the same asset on the same network that the invoice names. USDT in particular exists on several networks (TRC-20, ERC-20, TON and others), and they are not interchangeable. USDT sent on the wrong network usually can't be recovered, because the receiving address doesn't control that chain.

3. Send the exact amount

Copy the address from the invoice, never retype it, and compare the first and last characters after pasting. If you send too little, the invoice stays open; if you send too much, the difference is normally credited to your account balance.

4. Wait for confirmations

TRC-20 and TON usually confirm in under a minute; BTC takes about ten minutes per confirmation. Once the network confirms, the invoice is marked paid and the server is provisioned automatically — typically a few minutes later you receive the IP address, root credentials and a link to the control panel.

Mistakes that cost real money

• Wrong network. The classic one. Check twice.
• Sending from an exchange and expecting instant arrival. Exchanges batch withdrawals; allow extra time.
• Posting screenshots that show your address and balance. Not dangerous, but pointless.

What a legitimate provider never asks for

A seed phrase, a private key, or remote access to your computer. Payment goes to the address on your invoice — nowhere else. If someone claiming to be "support" asks you to send crypto to a different address, it is not the provider.

Do I need ID?

For crypto invoices at our checkout, no documents are required. Card payments go through a payment processor, which may run its own standard checks.

Want the full walkthrough?

A longer step-by-step version, with a short FAQ: https://buran.host/guides/pay-with-crypto

Plans start at €12/month for 4 vCPU, 8 GB RAM and 100 GB SSD with a dedicated IPv4 address: https://buran.host/vps