Guides

How these guides are written

Every guide here was written against a clean instance, not copied from a forum thread. Commands are shown exactly as you would type them. Where a step prints something you should check, the expected output is printed too, so you can tell the difference between "worked" and "silently did nothing".

We assume you are comfortable in a shell, can edit a file with nano or vim, and know what sudo does. We do not assume you have done any of this before on a server facing the public internet. That gap is where most outages and break-ins start.

Start here

• First-hour checklist: the ten things to do on a new instance before you deploy anything to it.
• SSH hardening: keys only, no root password login, a non-root user, and a sane sshd_config drop-in.
• nftables firewall: a default-drop ruleset you can read in one screen, plus how it interacts with the portal firewall.

Serving traffic

• nginx with TLS from Certbot: a reverse proxy in front of your app, automatic renewal, and HTTP/2 switched on.
• Docker Compose in production: restart policies, log limits, health checks, and keeping the Docker daemon from opening ports behind your firewall.
• PHP-FPM tuning: sizing pm.max_children from real memory use instead of guessing, and enabling OPcache properly.
• Git push to deploy: a bare repository, a post-receive hook, and atomic release directories with instant rollback.

Networking

• WireGuard VPN: a private tunnel from your laptop or office to the instance in about fifteen lines of config.
• Measuring latency: using mtr, ping and iperf3 to see what the network is actually doing between you and London.

Data and reliability

• Backups and snapshots: what a snapshot protects you from, what it does not, and an off-box backup routine that does.
• Database tuning on NVMe: PostgreSQL and MySQL settings that assume fast random I/O rather than spinning disks.
• Zero-downtime migration: moving a live site to a new instance with DNS TTL planning, a final sync and a tested cut-over.

Operations

• systemd timers: replacing cron jobs with units that log, retry and tell you when they last ran.
• Monitoring basics: disk, memory and service checks that catch a full disk before it takes the database down.
• Performance triage: a five-minute routine for "the server is slow" using top, iostat, ss and the journal.

Picking a plan to practise on

Every guide works on the smallest instance. Spark gives you one vCPU, 2 GB of RAM and 20 GB of NVMe-backed storage, which is plenty for learning nftables or WireGuard. The Docker and database guides are more comfortable from Boost upward, because container images and database buffers both want memory.

If you are following a guide to test something before production, take a snapshot from the portal once the base system is ready. Rolling back to it is faster than reinstalling and redoing the checklist.

Conventions

Lines starting with $ run as your normal user. Lines starting with # inside a code block are comments, not root prompts; we use sudo explicitly instead. Placeholders look like example.com or 203.0.113.10; swap in your own domain and the IPv4 address shown on the instance page in the portal.

When a guide edits a configuration file, it prefers a drop-in file such as /etc/ssh/sshd_config.d/10-local.conf over editing the distribution's main file. Package upgrades then leave your changes alone, and you can see exactly what you changed by listing one directory.